Le 2012-03-07 à 11:39:00, Roman Haefeli a écrit :
From the many backtraces I collected, most of them look very similar:
If the crashes vary and happen at seemingly random times, then there might be a single bug with different manifestations. If you patch takes a very low percentage of CPU, you may try running it with Valgrind, which might be able to find a cause for it, usually « Invalid Write », and sometimes might even be able to find a cause to the cause.
However, it's also possible that there are several bugs at once, who knows...
#2 0x00508b79 in iemnet__receiver_destroy () from /usr/local/lib/pd/extra/iemnet/libiemnet.so #3 0x08211148 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) (What does the last line mean?)
Something blew the backtrace. If it happens at #0, then it's possible that running unwanted code causes the stack to not be findable, but at #3, it's more like the stack is findable but got damaged, possibly by writing past the end of a C array on the stack (non-malloc).
What can I do to help to track down the reason for those crashes? Would using valgrind reveal more useful information here?
If the crashes are random-looking, or otherwise mysterious, Valgrind is always a good guess.
Is it possible to tell from the backtraces, whether the cause is in Pd itself or in the externals used?
From the backtrace of GDB, you can't be super sure. This points at awell-tested part of Pd. It would be a bit weird if it crashed here because of a bug in that part of pd, except if it happened in a test version of Pd that happened to have modifs in that area of the project.
______________________________________________________________________ | Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
_______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
