(I somehow missed to reply to the list; sorry for double-posting, Matju)
Hi Matju
Thanks a lot for your expertise.
On Sat, 2012-03-10 at 23:07 -0500, Mathieu Bouchard wrote:
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 a well-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.
I tested with an unmodified Pd source from git. My problem is that I cannot exclude the externals used, as I need them for running the setup that triggers the crashes. And yes, the CPU load average is usually moderate when it happens, but there might be some spikes for a few milliseconds.
I'll try to get more info with valgrind.
Roman