Program crashes after changing cell in QTableWidget

[code_err]

Hello, I have a following problem.
There is a QTableWidget with all cells filled with QTableWidgetItem objects.
When I get signal cellChanged(int row, int column) inside connected slot I'm trying to get data from remote server and then populate cell with text. It takes a while to get data (about 500ms). In the same time when I click on a different cell and start to populate it with text program crashes. What is the reason? I was trying to embrace entire slot function with mutex.lock()/mutex.unlock but it seems not to work.

[d_stranz]

Usually when a program crashes it is due to a bug in your code. Have you run your program in the debugger to see why and where it crashes?

[code_err]

Normally I would do this but I've just started to work with QtCreator and debugging seems not to work. When I start debugging in debug mode it looks like debugging is starting but it stops on constantly loading/unloading shell32.dll and nothing happens. Then I can only stop debugger.

I think that it may be because of manipulating (reading) of table's cells in slot while in the same time I click on the cell that is being read and change content, but I'm not sure. I thought that it should work in different way, that only after slot function ends I would be able to click on second cell to edit it. It seems that these operations are independent.

---

Added after 4 minutes:

...no, I've just created some testing code and it does work that way. There must be some other problem that I cannot find without debugger.

[anda_skoa]

While the effect of event based programming can often look like concurrency, it is not, so using mutexes will not only not help, it can easily lead to a dead lock.

Since you have not posted any code I can only assume you are using a pseudo-synchronous approach, e.g. a nested even loop or looping and calling process events.

If you do that you need to ensure that you do not use any member variables to store request data or context, since every eother invocation will overwrite these again.
It could be done with some form of associated container or even better fully asynchronous and using a request handler that encapsulates such an update.

Of course all highly theoretical, since we have no indication what you are actually doing.

Cheers,
_