An advice needed to catch Segmentation Violation
-
Hi all,
I know that my question is not in a good form, but I'm lost with it for several months already so I decided to ask it as is.I have a python GUI application written with Qt. The problem happens in following way. User selects menu item and opens a child MDI window. This window contains QTableView that displays data from a model based on parameters selected by user. So, the user may select, for example, another date in QDateEdit or another item in a drop-down list from QComboBox. A change of these widgets triggers a slot that provides new parameters to the model - as result data in the model are changed and user see different numbers in the table.
Everything works fine except one thing - sometimes the application crashes with Segmentation Violation after change of any parameter. It happens not often, for sure less then 5% of cases. It happens randomly - I can't reproduce the problem by repetition of the same sequence of actions (I tried many times in different scenario). It feels like some kind of race condition...
I another similar MDI windows in my application (but they have a bit simpler models) - they never crashed, the problem happens only with one particular window. But I can't spot the difference to reduce the example for better debugging...So, as I suffer from this problem for a long time and ran out of ideas I decided to ask an advice of how to catch this problem or at least make a next step in this direction.
-
Hi all,
I know that my question is not in a good form, but I'm lost with it for several months already so I decided to ask it as is.I have a python GUI application written with Qt. The problem happens in following way. User selects menu item and opens a child MDI window. This window contains QTableView that displays data from a model based on parameters selected by user. So, the user may select, for example, another date in QDateEdit or another item in a drop-down list from QComboBox. A change of these widgets triggers a slot that provides new parameters to the model - as result data in the model are changed and user see different numbers in the table.
Everything works fine except one thing - sometimes the application crashes with Segmentation Violation after change of any parameter. It happens not often, for sure less then 5% of cases. It happens randomly - I can't reproduce the problem by repetition of the same sequence of actions (I tried many times in different scenario). It feels like some kind of race condition...
I another similar MDI windows in my application (but they have a bit simpler models) - they never crashed, the problem happens only with one particular window. But I can't spot the difference to reduce the example for better debugging...So, as I suffer from this problem for a long time and ran out of ideas I decided to ask an advice of how to catch this problem or at least make a next step in this direction.
@StarterKit
Nobody will be able to guess from the description. If it's "random", do you use threads anywhere in your code?First you should run under Python debugger. Do you get any stack trace when it seg faults? That may be untrappable from Python debugger. So then try running the actual Python executable with arguments (
python3 myscript.py) under a C++ debugger (gdb, MSVC), what does its stack trace show when your Python crashes? -
@StarterKit
Nobody will be able to guess from the description. If it's "random", do you use threads anywhere in your code?First you should run under Python debugger. Do you get any stack trace when it seg faults? That may be untrappable from Python debugger. So then try running the actual Python executable with arguments (
python3 myscript.py) under a C++ debugger (gdb, MSVC), what does its stack trace show when your Python crashes?@JonB,
yes, I know that description is vague. I just understand that I reached the limits of my knowledge/experience and look for some new ideas what to try.No, I don't use threads in my application yet. I plan but with these kind of unresolved problems I don't think it is a wise move. So there might be some threads that Qt creates under the hood (to work with Camera for example) but from what I know this particular window has nothing to do and shouldn't be impacted by any thread operation.
Frankly, I rarely ran gdb, so I haven't thought of its usage for python program. I'll try it and come back as soon as I catch something.
-
@JonB,
yes, I know that description is vague. I just understand that I reached the limits of my knowledge/experience and look for some new ideas what to try.No, I don't use threads in my application yet. I plan but with these kind of unresolved problems I don't think it is a wise move. So there might be some threads that Qt creates under the hood (to work with Camera for example) but from what I know this particular window has nothing to do and shouldn't be impacted by any thread operation.
Frankly, I rarely ran gdb, so I haven't thought of its usage for python program. I'll try it and come back as soon as I catch something.
@StarterKit First see what happens in Python debugger. Maybe that catches your seg fault? gdb after that, but that for sure won't show what in Python is causing crash, just maybe a clue from C++, but may not reveal much.
-
@StarterKit First see what happens in Python debugger. Maybe that catches your seg fault? gdb after that, but that for sure won't show what in Python is causing crash, just maybe a clue from C++, but may not reveal much.
@JonB in python I see only Segmentation Violation and nothing else:
Process finished with exit code 139 (interrupted by signal 11:SIGSEGV) -
@JonB in python I see only Segmentation Violation and nothing else:
Process finished with exit code 139 (interrupted by signal 11:SIGSEGV)I spent some time yesterday trying to reproduce the case but was not successful (but it failed a day before with the same code so I'm sure the problem was there...).
This makes me a bit frustrated that I can't find a way how to reproduce it reliably.
What I do:- I change GUI element that triggers a slot where model parameters are set.
- As result model data are cleaned and new set of data is fetched.
- Then
modelResetis emitted to update QTreeView expandAll()is called to expand everything.
I use custom model and delegates derived from QStyledItemDelegate so I have 2 major suspects:
- that my model might do something wrong or don't do something mandatory when I reset its content.
- that delegate may be recreated in some not good moment.
I passed my model to
QAbstractItemModelTesterand it found several problems with indices. I reviewed Qt examples and was able to fix these problems - so my model passesQAbstractItemModelTestersuccessfully now.I'm not sure that it is a final fix as I was not able to reproduce the problem - I'll need some time to see has problem gone or not... So, I would be glad to hear what would be good to check additionally for the kind of use case that I described above.
-
I spent some time yesterday trying to reproduce the case but was not successful (but it failed a day before with the same code so I'm sure the problem was there...).
This makes me a bit frustrated that I can't find a way how to reproduce it reliably.
What I do:- I change GUI element that triggers a slot where model parameters are set.
- As result model data are cleaned and new set of data is fetched.
- Then
modelResetis emitted to update QTreeView expandAll()is called to expand everything.
I use custom model and delegates derived from QStyledItemDelegate so I have 2 major suspects:
- that my model might do something wrong or don't do something mandatory when I reset its content.
- that delegate may be recreated in some not good moment.
I passed my model to
QAbstractItemModelTesterand it found several problems with indices. I reviewed Qt examples and was able to fix these problems - so my model passesQAbstractItemModelTestersuccessfully now.I'm not sure that it is a final fix as I was not able to reproduce the problem - I'll need some time to see has problem gone or not... So, I would be glad to hear what would be good to check additionally for the kind of use case that I described above.
@StarterKit
Can't you at least put a whole bunch ofprint()statements in, or log to file, whatever, till you can find the last line executed from your Python script for seg fault? In an hour(?) you could isolate the line. -
@StarterKit
Can't you at least put a whole bunch ofprint()statements in, or log to file, whatever, till you can find the last line executed from your Python script for seg fault? In an hour(?) you could isolate the line.@JonB, it seems this is the most viable strategy.
The main problem now - it happens quite rare - I can't reproduce it for last 2 days. So yes, I'll do a lot of prints - this way probably I'll find the line that triggers the crash... But it is for sure not an hour - hopefully a week. The problem happens after very simple action but I may do the same many times successfully and then, occasionally, it crashes. But I can't trigger it by myself :( -
@JonB, it seems this is the most viable strategy.
The main problem now - it happens quite rare - I can't reproduce it for last 2 days. So yes, I'll do a lot of prints - this way probably I'll find the line that triggers the crash... But it is for sure not an hour - hopefully a week. The problem happens after very simple action but I may do the same many times successfully and then, occasionally, it crashes. But I can't trigger it by myself :(@StarterKit I meant an hour of putting in some
print()/logging statements all over the place, then letting it run to reproduce in time. -
@StarterKit I meant an hour of putting in some
print()/logging statements all over the place, then letting it run to reproduce in time.@JonB said in An advice needed to catch Segmentation Violation:
@StarterKit I meant an hour of putting in some
print()/logging statements all over the place, then letting it run to reproduce in time.Oh... sorry, got it from second reading only. Agree with you.
