Hello
Happy Easter everyone (for whom Easter is relevant)
I'm experiencing crashes on pd-extended (0.40.3 nightly) and 0.41 miller, with:
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xdfffedc4 0x0004326b in sys_domicrosleep (microsec=134217727, pollem=4427984) at s_inter.c:180 180 s_inter.c: No such file or directory. in s_inter.c Now, I realise that there is a static pointer between binbuf and s_inter.c in parsing messages from gui processes, but gdb will not tell me anymore about why this is crashing. Also, it doesn't crash at specific times. Sometimes when opening a patch, sometimes when saving it, etc. Anyone get the same problem? David
Looks like you're already using GDB to look at the crash, but apparently Pd wasn't compiled with GDB symbols... if I'm right about that, you might get more info (but Pd will run slower) if you 'make clean' and './configure --enable-debug' and then 'make'.
hope this helps... Miller
On Mon, Mar 24, 2008 at 01:21:06PM +0000, David Plans Casal wrote:
Hello
Happy Easter everyone (for whom Easter is relevant)
I'm experiencing crashes on pd-extended (0.40.3 nightly) and 0.41 miller, with:
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xdfffedc4 0x0004326b in sys_domicrosleep (microsec=134217727, pollem=4427984) at s_inter.c:180 180 s_inter.c: No such file or directory. in s_inter.c Now, I realise that there is a static pointer between binbuf and s_inter.c in parsing messages from gui processes, but gdb will not tell me anymore about why this is crashing. Also, it doesn't crash at specific times. Sometimes when opening a patch, sometimes when saving it, etc. Anyone get the same problem? David
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Mon, 24 Mar 2008, Miller Puckette wrote:
0x0004326b in sys_domicrosleep (microsec=134217727, pollem=4427984) at s_inter.c:180 180 s_inter.c: No such file or directory.
Looks like you're already using GDB to look at the crash, but apparently Pd wasn't compiled with GDB symbols... if I'm right about that,
No, this looks like Pd was compiled with GDB symbols, else you wouldn't see argument names, source file names, and line numbers.
However, full help from GDB requires source files to be present on the computer, preferably where they were when Pd was compiled, and if they're somewhere else, then GDB has to know, in order to have GDB automatically fetch lines from source.
Anyway, you don't need the lines from source. You have that source code. What you're missing is the rest of the backtrace (at least frame #1, perhaps #2), and the version number of the source.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On 25 Mar 2008, at 04:20, Mathieu Bouchard wrote:
On Mon, 24 Mar 2008, Miller Puckette wrote:
0x0004326b in sys_domicrosleep (microsec=134217727, pollem=4427984) at s_inter.c:180 180 s_inter.c: No such file or directory.
Looks like you're already using GDB to look at the crash, but apparently Pd wasn't compiled with GDB symbols... if I'm right about that,
No, this looks like Pd was compiled with GDB symbols, else you wouldn't see argument names, source file names, and line numbers.
Thank you for both answers; I was able to put breaks on s_inter.c and figure out py/pyext loading in a patch was the problem. For the archives, invoking py/pyext with anyother build but the one used to build that instance of py/pyext, causes crashes at the loader level, looks like.
David
-
David Plans Casal -
Mathieu Bouchard -
Miller Puckette