0

I have a program structure where my main calls (directly) 2 threads to run in parallel, one of these 2 calls another and this other calls other 2. So, I will have from 5 to 6 threads running at the same time.

This works, the problem is that at some point that I could not figure out how/why/when I get a Segmentation Fault Error, the program fully works 99.9% of the times, I tried to run (manually) several thread combination to "force" the seg fault, but for some reason, I am not able to.

The seg fault only kills part of the program which is the main issue. Since I can't really figure out why this is happening I want to handle it.

I tried to handle it with signal in the main thread. So, when the seg fault happens I would just kill every thread, but for some reason, the main thread does not receive the seg fault signal...

I have this on the beginning of my main: signal.signal(signal.SIGSEGV, sigHandler)

But when the seg fault happens my sigHandler is never called, I can't use signal in every thread because I get this error:

ValueError: signal only works in main thread

So, is there any other way to catch a seg fault that happened in one of the children threads in my main thread?

Gabrielle
  • 812
  • 2
  • 7
  • 28
  • Does it give you a stacktrace when it happens? If so, is that location consistent and can you do debugging around it? – Green Cloak Guy Aug 08 '18 at 15:16
  • 1
    You can't really handle it in Python in a sensible way. What you can do though is to run the python interpreter through GDB with your script. When the interpreter segfaults, GDB will stop all execution, and you can look into the various threads stacktraces to get a clue what goes wrong. – deets Aug 08 '18 at 15:17
  • Possibly related: https://stackoverflow.com/questions/10035541/what-causes-a-python-segmentation-fault – Jeremy Friesner Aug 08 '18 at 15:18
  • @GreenCloakGuy there's no stacktrace related with my code anyway... `Exception ignored in: ` `Traceback (most recent call last):` `Exception ignored in: >` `Traceback (most recent call last):` `objc[8660]: Invalid or prematurely-freed autorelease pool 0x7fa51739f788. Set a breakpoint on objc_autoreleasePoolInvalid to debug. Proceeding anyway because the app is old (SDK version 10.9.0). Memory errors are likely.` `Error in atexit._run_exitfuncs:` `Segmentation fault: 11` – Gabrielle Aug 08 '18 at 15:23
  • Are you by any chance using multi-threaded code to manipulate GUI-objects? – deets Aug 08 '18 at 15:24
  • @JeremyFriesner Although both talks about seg fault, it seems that they are trying to figure out what/when/how, I gave up of that.. I just want to handle the issue – Gabrielle Aug 08 '18 at 15:25
  • @Gabrielle you can't. A segfault means that the process is corrupted. You can't recover from that. You will have to get of the bottom of this. – deets Aug 08 '18 at 15:25
  • @deets Yes and No, In the beginning I have a GUI dialog, I close it, and start only background processes. One thing though is that my `wxPython` creates an app to show the dialog, and the app never leaves the taskbar (I have a thread opened about that and nobody could help me to destroy this app) – Gabrielle Aug 08 '18 at 15:26
  • @deets If this is the scenario, why only ONE of the threads die instead my main? I don't really want to "recover" I want to kill everything else.... the problem is that one thread dies but my main doesn't know about that – Gabrielle Aug 08 '18 at 15:28
  • Maybe you can point to the SO thread so I can take a look. The important bit in the meantime is: GUIs and multi-threading don't go along without utmost precaution. GUI-objects are ever only allowed to be manipulated by the main-thread. So if you have worker-threads you will need to use the appropriate means to communicate results to the main thread. I have no knowledge of wxPython (I don't like wx, but this is a personal matter). The ways to do this in other toolkits are e.g. timers, queued signals (in Qt) or "invoke in main thread" thingies (objective C/pyobjc). – deets Aug 08 '18 at 15:29
  • @Gabrielle there is no answer to this without further insights into the code and C-stack-traces. multi-threaded programming is nasty :( – deets Aug 08 '18 at 15:34
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/177659/discussion-between-gabrielle-and-deets). – Gabrielle Aug 08 '18 at 15:39

0 Answers0