Hi
after updating my debian installation (including 1ibc6) i suddenly started to have problems with pool. i have narrowed it down to this: closing pd after invoking [pool] in a patch, IF the xsample library is loaded, makes pd crash with the following message:
*** glibc detected *** double free or corruption (fasttop): 0x082d8ea8 ***
Sometimes this happens when just deleting an abstraction containing [pool]. I haven't been able to find a way to reproduce this, however.
the bt of gdb shows this:
0x40417861 in kill () from /lib/libc.so.6 (gdb) bt #0 0x40417861 in kill () from /lib/libc.so.6 #1 0x402b4309 in pthread_kill () from /lib/libpthread.so.0 #2 0x402b46c0 in raise () from /lib/libpthread.so.0 #3 0x40417616 in raise () from /lib/libc.so.6 #4 0x40418981 in abort () from /lib/libc.so.6 #5 0x4044a960 in __fsetlocking () from /lib/libc.so.6 #6 0x404502e9 in malloc_usable_size () from /lib/libc.so.6 #7 0x40450d81 in free () from /lib/libc.so.6 #8 0x4061e9d8 in flext_root_single::operator delete () from /usr/local/lib/pd/extra/xsample.pd_linux #9 0x4061bfaf in flext_base_single::AddOutlets () from /usr/local/lib/pd/extra/xsample.pd_linux #10 0x40419ade in exit () from /lib/libc.so.6 #11 0x4040441b in __libc_start_main () from /lib/libc.so.6 #12 0x08059261 in _start () at ../sysdeps/i386/elf/start.S:119
this is on devel 0_39, checked out today, and a recent (i believe yesterday) flext checkout, all compiled today.
If related somehow, the libc6 is 2.3.5-7, from unstable, the testing 2.3.5-6 had the same problem, while i didn't have this issue with 2.3.2.ds1-22 (_if_ it's related - if this will continue i guess i'll try to downgrade to see if it disappears).
i'd be grateful if anyone had any clues on how to solve this.
Johannes
this is on devel 0_39, checked out today, and a recent (i believe yesterday) flext checkout, all compiled today.
If related somehow, the libc6 is 2.3.5-7, from unstable, the testing 2.3.5-6 had the same problem, while i didn't have this issue with 2.3.2.ds1-22 (_if_ it's related - if this will continue i guess i'll try to downgrade to see if it disappears).
a quick solution would be to define FLEXT_NOGLOBALNEW when compiling your flext externals.
cheers ... tim
Hi
Tim Blechmann wrote:
a quick solution would be to define FLEXT_NOGLOBALNEW when compiling your flext externals.
I tried that, but pd still exits with the "double free" message, and sometimes (ie in a large patch with loads of xrecords and pools), segfaults when closing a patch. I will look a bit more into it later, to see if i've overlooked something... but if anyone has some, i'm open for suggestions.
thanks, Johannes
Hi Johannes, i would have been surprised if FLEXT_NOGLOBALNEW would have helped. In any case, i'm trying to track down the issue... it seems to be present in linux only. I hope valgrind can help me to find it shortly.
best greetings, Thomas
a quick solution would be to define FLEXT_NOGLOBALNEW when compiling your flext externals.
I tried that, but pd still exits with the "double free" message, and sometimes (ie in a large patch with loads of xrecords and pools), segfaults when closing a patch. I will look a bit more into it later, to see if i've overlooked something... but if anyone has some, i'm open for suggestions.
thanks, Johannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Johannes, i am trying around with pool and xsample using valgrind but the only violation i could provoke is on quitting PD which is unimportant (but shortly fixed nevertheless).
I've had a few reports concerning strange effects with flext-based externals (e.g. vanishing pool), and all of them have been on debian-unstable. When i get the chance to debug on such a machine, i'll research further but on my gentoo installation everything is running smooth at the moment.
If you could use the debug version of pool (built with "flext/build.sh pd gcc build-debug-single") and run pd with valgrind, some helpful information could probably be gathered.
many thanks, Thomas
Johannes Burström wrote:
Hi
after updating my debian installation (including 1ibc6) i suddenly started to have problems with pool. i have narrowed it down to this: closing pd after invoking [pool] in a patch, IF the xsample library is loaded, makes pd crash with the following message:
*** glibc detected *** double free or corruption (fasttop): 0x082d8ea8 ***
Sometimes this happens when just deleting an abstraction containing [pool]. I haven't been able to find a way to reproduce this, however.
the bt of gdb shows this:
0x40417861 in kill () from /lib/libc.so.6 (gdb) bt #0 0x40417861 in kill () from /lib/libc.so.6 #1 0x402b4309 in pthread_kill () from /lib/libpthread.so.0 #2 0x402b46c0 in raise () from /lib/libpthread.so.0 #3 0x40417616 in raise () from /lib/libc.so.6 #4 0x40418981 in abort () from /lib/libc.so.6 #5 0x4044a960 in __fsetlocking () from /lib/libc.so.6 #6 0x404502e9 in malloc_usable_size () from /lib/libc.so.6 #7 0x40450d81 in free () from /lib/libc.so.6 #8 0x4061e9d8 in flext_root_single::operator delete () from /usr/local/lib/pd/extra/xsample.pd_linux #9 0x4061bfaf in flext_base_single::AddOutlets () from /usr/local/lib/pd/extra/xsample.pd_linux #10 0x40419ade in exit () from /lib/libc.so.6 #11 0x4040441b in __libc_start_main () from /lib/libc.so.6 #12 0x08059261 in _start () at ../sysdeps/i386/elf/start.S:119
this is on devel 0_39, checked out today, and a recent (i believe yesterday) flext checkout, all compiled today.
If related somehow, the libc6 is 2.3.5-7, from unstable, the testing 2.3.5-6 had the same problem, while i didn't have this issue with 2.3.2.ds1-22 (_if_ it's related - if this will continue i guess i'll try to downgrade to see if it disappears).
i'd be grateful if anyone had any clues on how to solve this.
Johannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi
Thomas Grill wrote:
If you could use the debug version of pool (built with "flext/build.sh pd gcc build-debug-single") and run pd with valgrind, some helpful information could probably be gathered.
I've tried to make an easy patch to provoke a segfault, and finally found a good recipe... attached is "abs.pd" and "parent.pd". open parent with abs in path, and remove one or two instances of abs, perhaps undo once, and pd will eventually crash.
I compiled a debug version of pool, and did the above with valgrind. output is attached. it's the first time i've run valgrind, so i just ran it without any special arguments.. hope it can be of some use.
thanks, Johannes
many thanks, Thomas
Johannes Burström wrote:
Hi
after updating my debian installation (including 1ibc6) i suddenly started to have problems with pool. i have narrowed it down to this: closing pd after invoking [pool] in a patch, IF the xsample library is loaded, makes pd crash with the following message:
*** glibc detected *** double free or corruption (fasttop): 0x082d8ea8
Sometimes this happens when just deleting an abstraction containing [pool]. I haven't been able to find a way to reproduce this, however.
the bt of gdb shows this:
0x40417861 in kill () from /lib/libc.so.6 (gdb) bt #0 0x40417861 in kill () from /lib/libc.so.6 #1 0x402b4309 in pthread_kill () from /lib/libpthread.so.0 #2 0x402b46c0 in raise () from /lib/libpthread.so.0 #3 0x40417616 in raise () from /lib/libc.so.6 #4 0x40418981 in abort () from /lib/libc.so.6 #5 0x4044a960 in __fsetlocking () from /lib/libc.so.6 #6 0x404502e9 in malloc_usable_size () from /lib/libc.so.6 #7 0x40450d81 in free () from /lib/libc.so.6 #8 0x4061e9d8 in flext_root_single::operator delete () from /usr/local/lib/pd/extra/xsample.pd_linux #9 0x4061bfaf in flext_base_single::AddOutlets () from /usr/local/lib/pd/extra/xsample.pd_linux #10 0x40419ade in exit () from /lib/libc.so.6 #11 0x4040441b in __libc_start_main () from /lib/libc.so.6 #12 0x08059261 in _start () at ../sysdeps/i386/elf/start.S:119
this is on devel 0_39, checked out today, and a recent (i believe yesterday) flext checkout, all compiled today.
If related somehow, the libc6 is 2.3.5-7, from unstable, the testing 2.3.5-6 had the same problem, while i didn't have this issue with 2.3.2.ds1-22 (_if_ it's related - if this will continue i guess i'll try to downgrade to see if it disappears).
i'd be grateful if anyone had any clues on how to solve this.
Johannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
#N canvas 0 0 450 300 10; #X obj 138 108 pool;
#N canvas 0 0 450 300 10; #X obj 93 25 abs; #X obj 103 35 abs; #X obj 113 45 abs; #X obj 123 55 abs; #X obj 133 65 abs; #X obj 143 75 abs; #X text 103 146 removing an 'abs' crashes pd? (w/ xsample lib loaded);
==3113== Memcheck, a memory error detector for x86-linux. ==3113== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==3113== Using valgrind-2.4.0, a program supervision framework for x86-linux. ==3113== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==3113== ==3113== My PID = 3113, parent PID = 1438. Prog and args are: ==3113== pd ==3113== -lib ==3113== xsample ==3113== -rcfile ==3113== For more details, rerun with: -v ==3113== ==3113== Conditional jump or move depends on uninitialised value(s) ==3113== at 0x1B8ECB13: (within /lib/ld-2.3.5.so) ==3113== by 0x1B8E631C: (within /lib/ld-2.3.5.so) ==3113== by 0x1B8F2BDD: (within /lib/ld-2.3.5.so) ==3113== by 0x1B8E7675: (within /lib/ld-2.3.5.so) ==3113== by 0x1B8E47C6: (within /lib/ld-2.3.5.so) ==3113== ==3113== Conditional jump or move depends on uninitialised value(s) ==3113== at 0x1B8EC7D3: (within /lib/ld-2.3.5.so) ==3113== by 0x1B8E631C: (within /lib/ld-2.3.5.so) ==3113== by 0x1B8F2BDD: (within /lib/ld-2.3.5.so) ==3113== by 0x1B8E7675: (within /lib/ld-2.3.5.so) ==3113== by 0x1B8E47C6: (within /lib/ld-2.3.5.so) ==3113== ==3113== Conditional jump or move depends on uninitialised value(s) ==3113== at 0x1B8EC6B6: (within /lib/ld-2.3.5.so) ==3113== by 0x1B8E6376: (within /lib/ld-2.3.5.so) ==3113== by 0x1B8F2BDD: (within /lib/ld-2.3.5.so) ==3113== by 0x1B8E7675: (within /lib/ld-2.3.5.so) ==3113== by 0x1B8E47C6: (within /lib/ld-2.3.5.so) ==3113== ==3113== Conditional jump or move depends on uninitialised value(s) ==3113== at 0x1B8EC6C2: (within /lib/ld-2.3.5.so) ==3113== by 0x1B8E6376: (within /lib/ld-2.3.5.so) ==3113== by 0x1B8F2BDD: (within /lib/ld-2.3.5.so) ==3113== by 0x1B8E7675: (within /lib/ld-2.3.5.so) ==3113== by 0x1B8E47C6: (within /lib/ld-2.3.5.so) ==3113== ==3113== Conditional jump or move depends on uninitialised value(s) ==3113== at 0x1B8EC7D3: (within /lib/ld-2.3.5.so) ==3113== by 0x1B8E6376: (within /lib/ld-2.3.5.so) ==3113== by 0x1B8F2BDD: (within /lib/ld-2.3.5.so) ==3113== by 0x1B8E7675: (within /lib/ld-2.3.5.so) ==3113== by 0x1B8E47C6: (within /lib/ld-2.3.5.so) ==3113== ==3113== Syscall param open(filename) points to unaddressable byte(s) ==3113== at 0x1BD950D8: open (in /lib/libc-2.3.5.so) ==3113== by 0x1BD4670D: _IO_file_fopen (in /lib/libc-2.3.5.so) ==3113== by 0x1BD3DF06: (within /lib/libc-2.3.5.so) ==3113== by 0x1BD3DF5E: fopen (in /lib/libc-2.3.5.so) ==3113== by 0x808D07F: sys_parsercfile (s_path.c:385) ==3113== by 0x8089E9E: sys_argparse (s_main.c:835) ==3113== by 0x80889AC: sys_main (s_main.c:304) ==3113== by 0x8059325: main (s_entry.c:27) ==3113== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==3113== ==3113== Conditional jump or move depends on uninitialised value(s) ==3113== at 0x1B8EC6B6: (within /lib/ld-2.3.5.so) ==3113== by 0x1BDD2DF5: (within /lib/libc-2.3.5.so) ==3113== by 0x1B8EF026: (within /lib/ld-2.3.5.so) ==3113== by 0x1BDD3414: _dl_open (in /lib/libc-2.3.5.so) ==3113== by 0x1B918D2E: (within /lib/libdl-2.3.5.so) ==3113== by 0x1B8EF026: (within /lib/ld-2.3.5.so) ==3113== by 0x1B9192FF: (within /lib/libdl-2.3.5.so) ==3113== by 0x1B918D9C: dlopen (in /lib/libdl-2.3.5.so) ==3113== by 0x808837C: sys_load_lib (s_loader.c:110) ==3113== by 0x808874C: glob_initfromgui (s_main.c:246) ==3113== by 0x807DBDE: pd_typedmess (m_class.c:768) ==3113== by 0x807911A: binbuf_eval (m_binbuf.c:603) ==3113== ==3113== Conditional jump or move depends on uninitialised value(s) ==3113== at 0x1B8EC955: (within /lib/ld-2.3.5.so) ==3113== by 0x1BDD2DF5: (within /lib/libc-2.3.5.so) ==3113== by 0x1B8EF026: (within /lib/ld-2.3.5.so) ==3113== by 0x1BDD3414: _dl_open (in /lib/libc-2.3.5.so) ==3113== by 0x1B918D2E: (within /lib/libdl-2.3.5.so) ==3113== by 0x1B8EF026: (within /lib/ld-2.3.5.so) ==3113== by 0x1B9192FF: (within /lib/libdl-2.3.5.so) ==3113== by 0x1B918D9C: dlopen (in /lib/libdl-2.3.5.so) ==3113== by 0x808837C: sys_load_lib (s_loader.c:110) ==3113== by 0x808874C: glob_initfromgui (s_main.c:246) ==3113== by 0x807DBDE: pd_typedmess (m_class.c:768) ==3113== by 0x807911A: binbuf_eval (m_binbuf.c:603) ==3113== ==3113== Conditional jump or move depends on uninitialised value(s) ==3113== at 0x1B8ECAE6: (within /lib/ld-2.3.5.so) ==3113== by 0x1BDD2DF5: (within /lib/libc-2.3.5.so) ==3113== by 0x1B8EF026: (within /lib/ld-2.3.5.so) ==3113== by 0x1BDD3414: _dl_open (in /lib/libc-2.3.5.so) ==3113== by 0x1B918D2E: (within /lib/libdl-2.3.5.so) ==3113== by 0x1B8EF026: (within /lib/ld-2.3.5.so) ==3113== by 0x1B9192FF: (within /lib/libdl-2.3.5.so) ==3113== by 0x1B918D9C: dlopen (in /lib/libdl-2.3.5.so) ==3113== by 0x808837C: sys_load_lib (s_loader.c:110) ==3113== by 0x808874C: glob_initfromgui (s_main.c:246) ==3113== by 0x807DBDE: pd_typedmess (m_class.c:768) ==3113== by 0x807911A: binbuf_eval (m_binbuf.c:603) ==3113== ==3113== Conditional jump or move depends on uninitialised value(s) ==3113== at 0x1B8ECB13: (within /lib/ld-2.3.5.so) ==3113== by 0x1BDD2DF5: (within /lib/libc-2.3.5.so) ==3113== by 0x1B8EF026: (within /lib/ld-2.3.5.so) ==3113== by 0x1BDD3414: _dl_open (in /lib/libc-2.3.5.so) ==3113== by 0x1B918D2E: (within /lib/libdl-2.3.5.so) ==3113== by 0x1B8EF026: (within /lib/ld-2.3.5.so) ==3113== by 0x1B9192FF: (within /lib/libdl-2.3.5.so) ==3113== by 0x1B918D9C: dlopen (in /lib/libdl-2.3.5.so) ==3113== by 0x808837C: sys_load_lib (s_loader.c:110) ==3113== by 0x808874C: glob_initfromgui (s_main.c:246) ==3113== by 0x807DBDE: pd_typedmess (m_class.c:768) ==3113== by 0x807911A: binbuf_eval (m_binbuf.c:603) ==3113== ==3113== Conditional jump or move depends on uninitialised value(s) ==3113== at 0x1B8EC7D3: (within /lib/ld-2.3.5.so) ==3113== by 0x1BDD2DF5: (within /lib/libc-2.3.5.so) ==3113== by 0x1B8EF026: (within /lib/ld-2.3.5.so) ==3113== by 0x1BDD3414: _dl_open (in /lib/libc-2.3.5.so) ==3113== by 0x1B918D2E: (within /lib/libdl-2.3.5.so) ==3113== by 0x1B8EF026: (within /lib/ld-2.3.5.so) ==3113== by 0x1B9192FF: (within /lib/libdl-2.3.5.so) ==3113== by 0x1B918D9C: dlopen (in /lib/libdl-2.3.5.so) ==3113== by 0x808837C: sys_load_lib (s_loader.c:110) ==3113== by 0x808874C: glob_initfromgui (s_main.c:246) ==3113== by 0x807DBDE: pd_typedmess (m_class.c:768) ==3113== by 0x807911A: binbuf_eval (m_binbuf.c:603) ==3113== ==3113== Use of uninitialised value of size 4 ==3113== at 0x807DE6C: pd_typedmess (m_class.c:835) ==3113== by 0x807911A: binbuf_eval (m_binbuf.c:603) ==3113== by 0x8086F4C: socketreceiver_read (s_inter.c:572) ==3113== by 0x808657E: sys_pollsockets (s_inter.c:177) ==3113== by 0x808763A: sys_pollgui (s_inter.c:855) ==3113== by 0x8081D3D: m_scheduler (m_sched.c:555) ==3113== by 0x8088A6F: sys_main (s_main.c:358) ==3113== by 0x8059325: main (s_entry.c:27) ==3113== ==3113== Use of uninitialised value of size 4 ==3113== at 0x807DE6C: pd_typedmess (m_class.c:835) ==3113== by 0x80CBEB6: guiconnect_anything (g_guiconnect.c:70) ==3113== by 0x807E0D7: pd_typedmess (m_class.c:852) ==3113== by 0x807911A: binbuf_eval (m_binbuf.c:603) ==3113== by 0x8086F4C: socketreceiver_read (s_inter.c:572) ==3113== by 0x808657E: sys_pollsockets (s_inter.c:177) ==3113== by 0x808763A: sys_pollgui (s_inter.c:855) ==3113== by 0x8081D3D: m_scheduler (m_sched.c:555) ==3113== by 0x8088A6F: sys_main (s_main.c:358) ==3113== by 0x8059325: main (s_entry.c:27) ==3113== ==3113== Conditional jump or move depends on uninitialised value(s) ==3113== at 0x1C1E87FC: flext_base_single_d::Exit() (flext.cpp:117) ==3113== by 0x1C1EA8C0: flext_obj_single_d::obj_free(flext_hdr*) (fllib.cpp:524) ==3113== by 0x8080728: pd_free (m_pd.c:29) ==3113== by 0x80C8A4C: glist_delete (g_graph.c:120) ==3113== by 0x80BF96D: canvas_free (g_canvas.c:888) ==3113== by 0x8080728: pd_free (m_pd.c:29) ==3113== by 0x80C6120: canvas_menuclose (g_editor.c:1742) ==3113== by 0x807DDF5: pd_typedmess (m_class.c:831) ==3113== by 0x80CBEB6: guiconnect_anything (g_guiconnect.c:70) ==3113== by 0x807E0D7: pd_typedmess (m_class.c:852) ==3113== by 0x807911A: binbuf_eval (m_binbuf.c:603) ==3113== by 0x8086F4C: socketreceiver_read (s_inter.c:572) ==3113== ==3113== Use of uninitialised value of size 4 ==3113== at 0x808070A: pd_free (m_pd.c:28) ==3113== by 0x1C1E8818: flext_base_single_d::Exit() (flext.cpp:120) ==3113== by 0x1C1EA8C0: flext_obj_single_d::obj_free(flext_hdr*) (fllib.cpp:524) ==3113== by 0x8080728: pd_free (m_pd.c:29) ==3113== by 0x80C8A4C: glist_delete (g_graph.c:120) ==3113== by 0x80BF96D: canvas_free (g_canvas.c:888) ==3113== by 0x8080728: pd_free (m_pd.c:29) ==3113== by 0x80C6120: canvas_menuclose (g_editor.c:1742) ==3113== by 0x807DDF5: pd_typedmess (m_class.c:831) ==3113== by 0x80CBEB6: guiconnect_anything (g_guiconnect.c:70) ==3113== by 0x807E0D7: pd_typedmess (m_class.c:852) ==3113== by 0x807911A: binbuf_eval (m_binbuf.c:603) ==3113== ==3113== Invalid read of size 4 ==3113== at 0x8080712: pd_free (m_pd.c:29) ==3113== by 0x1C1E8818: flext_base_single_d::Exit() (flext.cpp:120) ==3113== by 0x1C1EA8C0: flext_obj_single_d::obj_free(flext_hdr*) (fllib.cpp:524) ==3113== by 0x8080728: pd_free (m_pd.c:29) ==3113== by 0x80C8A4C: glist_delete (g_graph.c:120) ==3113== by 0x80BF96D: canvas_free (g_canvas.c:888) ==3113== by 0x8080728: pd_free (m_pd.c:29) ==3113== by 0x80C6120: canvas_menuclose (g_editor.c:1742) ==3113== by 0x807DDF5: pd_typedmess (m_class.c:831) ==3113== by 0x80CBEB6: guiconnect_anything (g_guiconnect.c:70) ==3113== by 0x807E0D7: pd_typedmess (m_class.c:852) ==3113== by 0x807911A: binbuf_eval (m_binbuf.c:603) ==3113== Address 0x1BEE50F8 is not stack'd, malloc'd or (recently) free'd ==3113== ==3113== Invalid read of size 1 ==3113== at 0x808072C: pd_free (m_pd.c:30) ==3113== by 0x1C1E8818: flext_base_single_d::Exit() (flext.cpp:120) ==3113== by 0x1C1EA8C0: flext_obj_single_d::obj_free(flext_hdr*) (fllib.cpp:524) ==3113== by 0x8080728: pd_free (m_pd.c:29) ==3113== by 0x80C8A4C: glist_delete (g_graph.c:120) ==3113== by 0x80BF96D: canvas_free (g_canvas.c:888) ==3113== by 0x8080728: pd_free (m_pd.c:29) ==3113== by 0x80C6120: canvas_menuclose (g_editor.c:1742) ==3113== by 0x807DDF5: pd_typedmess (m_class.c:831) ==3113== by 0x80CBEB6: guiconnect_anything (g_guiconnect.c:70) ==3113== by 0x807E0D7: pd_typedmess (m_class.c:852) ==3113== by 0x807911A: binbuf_eval (m_binbuf.c:603) ==3113== Address 0x1BEE5129 is 5 bytes after a block of size 12 alloc'd ==3113== at 0x1B904F75: calloc (vg_replace_malloc.c:175) ==3113== by 0x807EE95: getbytes (m_memory.c:25) ==3113== by 0x807D639: dogensym (m_class.c:582) ==3113== by 0x807D6A5: gensym (m_class.c:598) ==3113== by 0x806AE39: sigwrap_setup (d_math.c:274) ==3113== by 0x806B9CF: d_math_setup (d_math.c:574) ==3113== by 0x807E4CF: conf_init (m_conf.c:44) ==3113== by 0x8080EB8: pd_init (m_pd.c:306) ==3113== by 0x80888D5: sys_main (s_main.c:280) ==3113== by 0x8059325: main (s_entry.c:27) ==3113== ==3113== Invalid read of size 4 ==3113== at 0x8080783: pd_free (m_pd.c:39) ==3113== by 0x1C1E8818: flext_base_single_d::Exit() (flext.cpp:120) ==3113== by 0x1C1EA8C0: flext_obj_single_d::obj_free(flext_hdr*) (fllib.cpp:524) ==3113== by 0x8080728: pd_free (m_pd.c:29) ==3113== by 0x80C8A4C: glist_delete (g_graph.c:120) ==3113== by 0x80BF96D: canvas_free (g_canvas.c:888) ==3113== by 0x8080728: pd_free (m_pd.c:29) ==3113== by 0x80C6120: canvas_menuclose (g_editor.c:1742) ==3113== by 0x807DDF5: pd_typedmess (m_class.c:831) ==3113== by 0x80CBEB6: guiconnect_anything (g_guiconnect.c:70) ==3113== by 0x807E0D7: pd_typedmess (m_class.c:852) ==3113== by 0x807911A: binbuf_eval (m_binbuf.c:603) ==3113== Address 0x1BEE50EC is 4 bytes after a block of size 8 alloc'd ==3113== at 0x1B904F75: calloc (vg_replace_malloc.c:175) ==3113== by 0x807EE95: getbytes (m_memory.c:25) ==3113== by 0x807D64A: dogensym (m_class.c:583) ==3113== by 0x807D6A5: gensym (m_class.c:598) ==3113== by 0x80C0CCC: g_canvas_setup (g_canvas.c:1489) ==3113== by 0x807E44D: conf_init (m_conf.c:37) ==3113== by 0x8080EB8: pd_init (m_pd.c:306) ==3113== by 0x80888D5: sys_main (s_main.c:280) ==3113== by 0x8059325: main (s_entry.c:27) ==3113== ==3113== Invalid read of size 4 ==3113== at 0x808070A: pd_free (m_pd.c:28) ==3113== by 0x1C1E8818: flext_base_single_d::Exit() (flext.cpp:120) ==3113== by 0x1C1EA8C0: flext_obj_single_d::obj_free(flext_hdr*) (fllib.cpp:524) ==3113== by 0x8080728: pd_free (m_pd.c:29) ==3113== by 0x80C8A4C: glist_delete (g_graph.c:120) ==3113== by 0x80CB6DA: graph_delete (g_graph.c:989) ==3113== by 0x80C155C: gobj_delete (g_editor.c:62) ==3113== by 0x80C8999: glist_delete (g_graph.c:108) ==3113== by 0x80C6E0F: canvas_doclear (g_editor.c:2082) ==3113== by 0x80C59AB: canvas_key (g_editor.c:1595) ==3113== by 0x807DBDE: pd_typedmess (m_class.c:768) ==3113== by 0x80CBEB6: guiconnect_anything (g_guiconnect.c:70) ==3113== Address 0xA is not stack'd, malloc'd or (recently) free'd ==3113== ==3113== Process terminating with default action of signal 11 (SIGSEGV) ==3113== Access not within mapped region at address 0xA ==3113== at 0x808070A: pd_free (m_pd.c:28) ==3113== by 0x1C1E8818: flext_base_single_d::Exit() (flext.cpp:120) ==3113== by 0x1C1EA8C0: flext_obj_single_d::obj_free(flext_hdr*) (fllib.cpp:524) ==3113== by 0x8080728: pd_free (m_pd.c:29) ==3113== by 0x80C8A4C: glist_delete (g_graph.c:120) ==3113== by 0x80CB6DA: graph_delete (g_graph.c:989) ==3113== by 0x80C155C: gobj_delete (g_editor.c:62) ==3113== by 0x80C8999: glist_delete (g_graph.c:108) ==3113== by 0x80C6E0F: canvas_doclear (g_editor.c:2082) ==3113== by 0x80C59AB: canvas_key (g_editor.c:1595) ==3113== by 0x807DBDE: pd_typedmess (m_class.c:768) ==3113== by 0x80CBEB6: guiconnect_anything (g_guiconnect.c:70) ==3113== ==3113== ERROR SUMMARY: 62 errors from 19 contexts (suppressed: 0 from 0) ==3113== malloc/free: in use at exit: 107410 bytes in 2217 blocks. ==3113== malloc/free: 3378 allocs, 1161 frees, 1473596 bytes allocated. ==3113== For counts of detected errors, rerun with: -v ==3113== searching for pointers to 2217 not-freed blocks. ==3113== checked 2182688 bytes. ==3113== ==3113== LEAK SUMMARY: ==3113== definitely lost: 386 bytes in 10 blocks. ==3113== possibly lost: 10200 bytes in 243 blocks. ==3113== still reachable: 96824 bytes in 1964 blocks. ==3113== suppressed: 0 bytes in 0 blocks. ==3113== Use --leak-check=full to see details of leaked memory.
Hi Johannes, thanks for your report.
I tried your patch (it's good to give the abs abstraction another name, since abs is an internal object), but everything works as expected both with Miller's PD and with devel_0_39. Not a single valgrind message is generated here (apart from a harmless one from inside pthreads). It seems there's something strange with your system that is beyond my scope. I'm curious about more observations though.
best greetings, Thomas
Johannes Burström wrote:
Hi
Thomas Grill wrote:
If you could use the debug version of pool (built with "flext/build.sh pd gcc build-debug-single") and run pd with valgrind, some helpful information could probably be gathered.
I've tried to make an easy patch to provoke a segfault, and finally found a good recipe... attached is "abs.pd" and "parent.pd". open parent with abs in path, and remove one or two instances of abs, perhaps undo once, and pd will eventually crash.
I compiled a debug version of pool, and did the above with valgrind. output is attached. it's the first time i've run valgrind, so i just ran it without any special arguments.. hope it can be of some use.
thanks, Johannes
Hallo, Johannes Burström hat gesagt: // Johannes Burström wrote:
Thomas Grill wrote:
If you could use the debug version of pool (built with "flext/build.sh pd gcc build-debug-single") and run pd with valgrind, some helpful information could probably be gathered.
I've tried to make an easy patch to provoke a segfault, and finally found a good recipe... attached is "abs.pd" and "parent.pd". open parent with abs in path, and remove one or two instances of abs, perhaps undo once, and pd will eventually crash.
Being on Debian myself, I tested your patch. It does not crash Pd, however I also always get the glibc message, if I end Pd, and sometimes Pd doesn't properly close itself. That is, only the GUI kind of stops, the server keeps running until I Ctl-C it. This doesn't happen all the time, though.
All this can be made to stop by not loading the xsample library, which I don't use that often, so for me it's no big deal.
Frank Barknecht _ ______footils.org_ __goto10.org__
Hi Frank, does this double-free error message only happen on quitting PD? This one i could reproduce and should be fixed now (i just synced the cvs). The error Johannes reported seems to be different since it happens on destroying flext-based objects... i have no clue about that one.
best greetings, Thomas
Am 07.11.2005 um 09:35 schrieb Frank Barknecht:
Hallo, Johannes Burström hat gesagt: // Johannes Burström wrote:
Thomas Grill wrote:
If you could use the debug version of pool (built with "flext/build.sh pd gcc build-debug-single") and run pd with valgrind, some helpful information could probably be gathered.
I've tried to make an easy patch to provoke a segfault, and finally found a good recipe... attached is "abs.pd" and "parent.pd". open parent with abs in path, and remove one or two instances of abs, perhaps undo once, and pd will eventually crash.
Being on Debian myself, I tested your patch. It does not crash Pd, however I also always get the glibc message, if I end Pd, and sometimes Pd doesn't properly close itself. That is, only the GUI kind of stops, the server keeps running until I Ctl-C it. This doesn't happen all the time, though.
All this can be made to stop by not loading the xsample library, which I don't use that often, so for me it's no big deal.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
does this double-free error message only happen on quitting PD? This one i could reproduce and should be fixed now (i just synced the cvs). The error Johannes reported seems to be different since it happens on destroying flext-based objects... i have no clue about that one.
Yes, it's only on quitting Pd, so it's not really an issue, just ugly. I'll check out your changes later. However I may add, that my Debian version is not "unstable", but the latest "stable" version (Sarge) with only a couple of packages from "testing".
Frank Barknecht _ ______footils.org_ __goto10.org__
On Nov 7, 2005, at 7:05 AM, Frank Barknecht wrote:
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
does this double-free error message only happen on quitting PD? This one i could reproduce and should be fixed now (i just synced the
cvs). The error Johannes reported seems to be different since it happens on destroying flext-based objects... i have no clue about that one.Yes, it's only on quitting Pd, so it's not really an issue, just ugly. I'll check out your changes later. However I may add, that my Debian version is not "unstable", but the latest "stable" version (Sarge) with only a couple of packages from "testing".
...hrmm, I'd hardly say "it's not really an issue"! I've also been
seeing this on the osx side (mentioned in pre-halloween posts as
"zombie pd"), and it's especially bad with the app_pkg builds,
because one often doesn't realize that the app hasn't fully quit when
asked, which brings up problems the next time you try to launch...
...also, this makes pd unusable in an "installation" setting, which
is what I have to deliver this week...I really don't want to show up
every morning and make sure there's only one pd running...tho come to
think of it, isn't there a quake-style "kill process" app? Would be
fun, if annoying, to wake up and blast zombie pd's over the net ;-p
...so I'd put this in the "must be fixed soon" category, but until
then, I gotta downgrade...
jamie
Hi Jamie,
...so I'd put this in the "must be fixed soon" category, but until then, I gotta downgrade...
i don't think you have to... it's not a PD but a flext issue (well it's more a compiler issue...) and should be fixed in current cvs.
best greetings, Thomas
Hallo, james tittle hat gesagt: // james tittle wrote:
On Nov 7, 2005, at 7:05 AM, Frank Barknecht wrote:
Yes, it's only on quitting Pd, so it's not really an issue, just ugly. I'll check out your changes later. However I may add, that my Debian version is not "unstable", but the latest "stable" version (Sarge) with only a couple of packages from "testing".
...hrmm, I'd hardly say "it's not really an issue"! I've also been
seeing this on the osx side (mentioned in pre-halloween posts as
"zombie pd"), and it's especially bad with the app_pkg builds,
because one often doesn't realize that the app hasn't fully quit when
asked, which brings up problems the next time you try to launch...
Most of the time Pd even quits, when the "double free" message appears. I have found no reliably way to reproduce the hanging Pd, though.
Anyway a "Ctl-C" in the Terminal or a "killall pd" "fixes" it just fine as does not using xsample with pool at the same time. (I didn't try Thomas' compiler fix yet.) So even in an installation settings is not something impossible to work around IMO.
...also, this makes pd unusable in an "installation" setting, which
is what I have to deliver this week...
You should be playing "Shadow of the Colossus" instead. ;)
Frank Barknecht _ ______footils.org_ __goto10.org__
Hi,
Frank Barknecht wrote:
Yes, it's only on quitting Pd, so it's not really an issue, just ugly. I'll check out your changes later. However I may add, that my Debian version is not "unstable", but the latest "stable" version (Sarge) with only a couple of packages from "testing".
well, everything was fine for me too until i upgraded some packages (including libc6) to testing/unstable. i guess my next (and only) move will be to downgrade those packages again, to see if the problem disappears. I'd be glad to do some more testing with this setup, to see what the problem might be, but since i'm no master debugger i really don't know where to start looking. After all, right now all i want is a working system...
it's a kind of catch 22. if i knew more about my system and debugging, i might be of some help to find the source of the problem. But on the other hand, if i new more about how to set up my system, i might not have put myself in this situation... :P
thanks for the help so far, anyway. i'll try the new flext version and see what it says to me.
Johannes
Just for the record:
Johannes Burström wrote:
well, everything was fine for me too until i upgraded some packages (including libc6) to testing/unstable. i guess my next (and only) move will be to downgrade those packages again, to see if the problem disappears.
I downgraded to the stable version of libc6 (2.3.2.ds1-22) (with a few packages following it), and now i don't get any crashes or "glibc double free..." messages. back to making music again...
regards, Johannes