Dear all, after managing again the flext installation (i took the newest version from cvs)-I still have the same glib-error.
gerda:~ pd -verbose
Pd version 0.39-1
compiled 16:05:47 Oct 28 2005
port 5401
TCL_LIBRARY="/usr/local/lib/pd/tcl/library"
TK_LIBRARY="/usr/local/lib/pd/tk/library"
"/usr/local/lib/pd/bin/pd-gui" 5401
Waiting for connection request...
... connected
PDP: pure data packet
PDP: version 0.12.4
*** glibc detected *** double free or corruption (fasttop): 0x08187ee0 ***
Pd: signal 6
Johannes Burström wrote: http://lists.puredata.info/pipermail/pd-list/2005-11/032513.html that he managed his problem with downgrading the libc6---do I actually have the same problem- should i also downgrade libc6 now?
thx Gerda
On Tue, 13 Dec 2005, Gerda Strobl wrote:
Johannes Burström wrote: http://lists.puredata.info/pipermail/pd-list/2005-11/032513.html that he managed his problem with downgrading the libc6---do I actually have the same problem- should i also downgrade libc6 now?
I'd rather have you post a backtrace. This will enable to fix the bug instead of just pretending that it doesn't exist.
Start Pd using the gdb program by prefixing your commandline with
gdb --args
and then type the "run" command. When the crash happens, use the "where"
command to find out how the crash happened. Post the report here. to leave
gdb, use "quit" or Ctrl+D; if you do Ctrl+C it won't work because that's
reserved for aborting the program that gdb is running.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Dear list, this is the output from using gdb:
(gdb) run Starting program: /usr/local/bin/pd [Thread debugging using libthread_db enabled] [New Thread -1210120512 (LWP 8469)] *** glibc detected *** double free or corruption (fasttop): 0x0816e808 ***
Program received signal SIGABRT, Aborted. [Switching to Thread -1210120512 (LWP 8469)] 0xb7e1a9e7 in raise () from /lib/tls/libc.so.6 (gdb) where #0 0xb7e1a9e7 in raise () from /lib/tls/libc.so.6 #1 0xb7e1c31b in abort () from /lib/tls/libc.so.6 #2 0xb7e51365 in __fsetlocking () from /lib/tls/libc.so.6 #3 0xb7e57a07 in malloc_usable_size () from /lib/tls/libc.so.6 #4 0xb7e57ea2 in free () from /lib/tls/libc.so.6 #5 0xb7ddd69c in flext_root_single::operator delete () from /usr/local/lib/pd/extra/pool.pd_linux #6 0xb7dd6386 in pooldir::Clear () from /usr/local/lib/pd/extra/pool.pd_linux #7 0xb7dd61db in pooldir::Reset () from /usr/local/lib/pd/extra/pool.pd_linux #8 0xb7dd62a4 in pooldir::~pooldir () from /usr/local/lib/pd/extra/pool.pd_linux #9 0xb7dd637e in pooldir::Clear () from /usr/local/lib/pd/extra/pool.pd_linux #10 0xb7dd61db in pooldir::Reset () from /usr/local/lib/pd/extra/pool.pd_linux #11 0xb7dd62a4 in pooldir::~pooldir () from /usr/local/lib/pd/extra/pool.pd_linux #12 0xb7dd40e0 in pooldata::~pooldata () from /usr/local/lib/pd/extra/pool.pd_linux #13 0xb7dcd7e2 in pool::RmvPool () from /usr/local/lib/pd/extra/pool.pd_linux #14 0xb7dcdb41 in pool::FreePool () from /usr/local/lib/pd/extra/pool.pd_linux #15 0xb7dcf2e2 in pool::~pool () from /usr/local/lib/pd/extra/pool.pd_linux #16 0xb7dd3228 in pool::__free__ () from /usr/local/lib/pd/extra/pool.pd_linux #17 0xb7dd9fd3 in flext_obj_single::obj_free () from /usr/local/lib/pd/extra/pool.pd_linux #18 0x0809f7e7 in pd_free (x=0x8178810) at m_pd.c:33 #19 0x08057709 in glist_delete (x=0x81784c8, y=0x8178810) at g_graph.c:120 #20 0x0805c83c in graph_delete (z=0x81784c8, glist=0x0) at g_graph.c:988 #21 0x08081d6e in gobj_delete (x=0x2115, glist=0x0) at g_editor.c:61 #22 0x080576bd in glist_delete (x=0x81622f8, y=0x81784c8) at g_graph.c:108 #23 0x0805c83c in graph_delete (z=0x81622f8, glist=0x0) at g_graph.c:988 #24 0x08081d6e in gobj_delete (x=0x2115, glist=0x0) at g_editor.c:61 #25 0x080576bd in glist_delete (x=0x81614e0, y=0x81622f8) at g_graph.c:108 #26 0x0805c83c in graph_delete (z=0x81614e0, glist=0x0) at g_graph.c:988 #27 0x08081d6e in gobj_delete (x=0x2115, glist=0x0) at g_editor.c:61 #28 0x080576bd in glist_delete (x=0x81612f0, y=0x81614e0) at g_graph.c:108 #29 0x08054a9c in canvas_free (x=0x81612f0) at g_canvas.c:875 #30 0x0809f7e7 in pd_free (x=0x81612f0) at m_pd.c:33 #31 0x080a094d in pd_typedmess (x=0x81612f0, s=0x2115, argc=135664368, argv=0x3f800000) at m_class.c:728 #32 0x080a0816 in pd_typedmess (x=0x816c3c8, s=0x2115, argc=1, argv=0x80f92a8) at m_class.c:749 #33 0x080a3cf4 in binbuf_eval (x=0x0, target=0x816c3c8, argc=0, argv=0x0) at m_binbuf.c:574 #34 0x080ac130 in socketreceiver_read (x=0x81144c8, fd=0) at s_inter.c:540 #35 0x080adcff in sys_domicrosleep (microsec=0, pollem=1) at s_inter.c:180 #36 0x080ad398 in sys_microsleep (microsec=0) at s_inter.c:202 #37 0x080a8b2f in m_scheduler () at m_sched.c:487 #38 0x080b351b in main (argc=0, argv=0x0) at s_entry.c:27 (gdb) quit The program is running. Exit anyway? (y or n) y socket receive error: Connection reset by peer (104)
lg Gerda Mathieu Bouchard wrote:
On Tue, 13 Dec 2005, Gerda Strobl wrote:
Johannes Burström wrote: http://lists.puredata.info/pipermail/pd-list/2005-11/032513.html that he managed his problem with downgrading the libc6---do I actually have the same problem- should i also downgrade libc6 now?
I'd rather have you post a backtrace. This will enable to fix the bug instead of just pretending that it doesn't exist.
Start Pd using the gdb program by prefixing your commandline with
gdb --args
and then type the "run" command. When the crash happens, use the "where"
command to find out how the crash happened. Post the report here. to leave gdb, use "quit" or Ctrl+D; if you do Ctrl+C it won't work because that's reserved for aborting the program that gdb is running._ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Oh wow, thanks for that one.... that's really news to me. Let's see if pool is responsible for that - although i haven't changed any relevant things for years now, i think.
greetings, Thomas
Am 13.12.2005 um 16:05 schrieb Gerda Strobl:
Dear list, this is the output from using gdb:
(gdb) run Starting program: /usr/local/bin/pd [Thread debugging using libthread_db enabled] [New Thread -1210120512 (LWP 8469)] *** glibc detected *** double free or corruption (fasttop): 0x0816e808
Program received signal SIGABRT, Aborted. [Switching to Thread -1210120512 (LWP 8469)] 0xb7e1a9e7 in raise () from /lib/tls/libc.so.6 (gdb) where #0 0xb7e1a9e7 in raise () from /lib/tls/libc.so.6 #1 0xb7e1c31b in abort () from /lib/tls/libc.so.6 #2 0xb7e51365 in __fsetlocking () from /lib/tls/libc.so.6 #3 0xb7e57a07 in malloc_usable_size () from /lib/tls/libc.so.6 #4 0xb7e57ea2 in free () from /lib/tls/libc.so.6 #5 0xb7ddd69c in flext_root_single::operator delete () from /usr/local/lib/pd/extra/pool.pd_linux #6 0xb7dd6386 in pooldir::Clear () from /usr/local/lib/pd/extra/pool.pd_linux #7 0xb7dd61db in pooldir::Reset () from /usr/local/lib/pd/extra/pool.pd_linux #8 0xb7dd62a4 in pooldir::~pooldir () from /usr/local/lib/pd/extra/pool.pd_linux #9 0xb7dd637e in pooldir::Clear () from /usr/local/lib/pd/extra/pool.pd_linux #10 0xb7dd61db in pooldir::Reset () from /usr/local/lib/pd/extra/pool.pd_linux #11 0xb7dd62a4 in pooldir::~pooldir () from /usr/local/lib/pd/extra/pool.pd_linux #12 0xb7dd40e0 in pooldata::~pooldata () from /usr/local/lib/pd/extra/pool.pd_linux #13 0xb7dcd7e2 in pool::RmvPool () from /usr/local/lib/pd/extra/pool.pd_linux #14 0xb7dcdb41 in pool::FreePool () from /usr/local/lib/pd/extra/pool.pd_linux #15 0xb7dcf2e2 in pool::~pool () from /usr/local/lib/pd/extra/pool.pd_linux #16 0xb7dd3228 in pool::__free__ () from /usr/local/lib/pd/extra/pool.pd_linux #17 0xb7dd9fd3 in flext_obj_single::obj_free () from /usr/local/lib/pd/extra/pool.pd_linux #18 0x0809f7e7 in pd_free (x=0x8178810) at m_pd.c:33 #19 0x08057709 in glist_delete (x=0x81784c8, y=0x8178810) at g_graph.c:120 #20 0x0805c83c in graph_delete (z=0x81784c8, glist=0x0) at g_graph.c:988 #21 0x08081d6e in gobj_delete (x=0x2115, glist=0x0) at g_editor.c:61 #22 0x080576bd in glist_delete (x=0x81622f8, y=0x81784c8) at g_graph.c:108 #23 0x0805c83c in graph_delete (z=0x81622f8, glist=0x0) at g_graph.c:988 #24 0x08081d6e in gobj_delete (x=0x2115, glist=0x0) at g_editor.c:61 #25 0x080576bd in glist_delete (x=0x81614e0, y=0x81622f8) at g_graph.c:108 #26 0x0805c83c in graph_delete (z=0x81614e0, glist=0x0) at g_graph.c:988 #27 0x08081d6e in gobj_delete (x=0x2115, glist=0x0) at g_editor.c:61 #28 0x080576bd in glist_delete (x=0x81612f0, y=0x81614e0) at g_graph.c:108 #29 0x08054a9c in canvas_free (x=0x81612f0) at g_canvas.c:875 #30 0x0809f7e7 in pd_free (x=0x81612f0) at m_pd.c:33 #31 0x080a094d in pd_typedmess (x=0x81612f0, s=0x2115, argc=135664368, argv=0x3f800000) at m_class.c:728 #32 0x080a0816 in pd_typedmess (x=0x816c3c8, s=0x2115, argc=1, argv=0x80f92a8) at m_class.c:749 #33 0x080a3cf4 in binbuf_eval (x=0x0, target=0x816c3c8, argc=0, argv=0x0) at m_binbuf.c:574 #34 0x080ac130 in socketreceiver_read (x=0x81144c8, fd=0) at s_inter.c:540 #35 0x080adcff in sys_domicrosleep (microsec=0, pollem=1) at s_inter.c:180 #36 0x080ad398 in sys_microsleep (microsec=0) at s_inter.c:202 #37 0x080a8b2f in m_scheduler () at m_sched.c:487 #38 0x080b351b in main (argc=0, argv=0x0) at s_entry.c:27 (gdb) quit The program is running. Exit anyway? (y or n) y socket receive error: Connection reset by peer (104)
lg Gerda Mathieu Bouchard wrote:
On Tue, 13 Dec 2005, Gerda Strobl wrote:
Johannes Burström wrote: http://lists.puredata.info/pipermail/pd-list/2005-11/032513.html that he managed his problem with downgrading the libc6---do I actually have the same problem- should i also downgrade libc6 now?
I'd rather have you post a backtrace. This will enable to fix the bug instead of just pretending that it doesn't exist.
Start Pd using the gdb program by prefixing your commandline with
gdb --args
and then type the "run" command. When the crash happens, use the "where" command to find out how the crash happened. Post the report here. to leave gdb, use "quit" or Ctrl+D; if you do Ctrl+C it won't work because that's reserved for aborting the program that gdb is running.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Gerda, can you post a simple patch using pool where this is happening? Please include detailed instructions how to reproduce the crash.
thanks, Thomas
Am 13.12.2005 um 16:05 schrieb Gerda Strobl:
Dear list, this is the output from using gdb:
(gdb) run Starting program: /usr/local/bin/pd [Thread debugging using libthread_db enabled] [New Thread -1210120512 (LWP 8469)] *** glibc detected *** double free or corruption (fasttop): 0x0816e808
Program received signal SIGABRT, Aborted. [Switching to Thread -1210120512 (LWP 8469)] 0xb7e1a9e7 in raise () from /lib/tls/libc.so.6 (gdb) where #0 0xb7e1a9e7 in raise () from /lib/tls/libc.so.6 #1 0xb7e1c31b in abort () from /lib/tls/libc.so.6 #2 0xb7e51365 in __fsetlocking () from /lib/tls/libc.so.6 #3 0xb7e57a07 in malloc_usable_size () from /lib/tls/libc.so.6 #4 0xb7e57ea2 in free () from /lib/tls/libc.so.6 #5 0xb7ddd69c in flext_root_single::operator delete () from /usr/local/lib/pd/extra/pool.pd_linux #6 0xb7dd6386 in pooldir::Clear () from /usr/local/lib/pd/extra/pool.pd_linux #7 0xb7dd61db in pooldir::Reset () from /usr/local/lib/pd/extra/pool.pd_linux #8 0xb7dd62a4 in pooldir::~pooldir () from /usr/local/lib/pd/extra/pool.pd_linux #9 0xb7dd637e in pooldir::Clear () from /usr/local/lib/pd/extra/pool.pd_linux #10 0xb7dd61db in pooldir::Reset () from /usr/local/lib/pd/extra/pool.pd_linux #11 0xb7dd62a4 in pooldir::~pooldir () from /usr/local/lib/pd/extra/pool.pd_linux #12 0xb7dd40e0 in pooldata::~pooldata () from /usr/local/lib/pd/extra/pool.pd_linux #13 0xb7dcd7e2 in pool::RmvPool () from /usr/local/lib/pd/extra/pool.pd_linux #14 0xb7dcdb41 in pool::FreePool () from /usr/local/lib/pd/extra/pool.pd_linux #15 0xb7dcf2e2 in pool::~pool () from /usr/local/lib/pd/extra/pool.pd_linux #16 0xb7dd3228 in pool::__free__ () from /usr/local/lib/pd/extra/pool.pd_linux #17 0xb7dd9fd3 in flext_obj_single::obj_free () from /usr/local/lib/pd/extra/pool.pd_linux #18 0x0809f7e7 in pd_free (x=0x8178810) at m_pd.c:33 #19 0x08057709 in glist_delete (x=0x81784c8, y=0x8178810) at g_graph.c:120 #20 0x0805c83c in graph_delete (z=0x81784c8, glist=0x0) at g_graph.c:988 #21 0x08081d6e in gobj_delete (x=0x2115, glist=0x0) at g_editor.c:61 #22 0x080576bd in glist_delete (x=0x81622f8, y=0x81784c8) at g_graph.c:108 #23 0x0805c83c in graph_delete (z=0x81622f8, glist=0x0) at g_graph.c:988 #24 0x08081d6e in gobj_delete (x=0x2115, glist=0x0) at g_editor.c:61 #25 0x080576bd in glist_delete (x=0x81614e0, y=0x81622f8) at g_graph.c:108 #26 0x0805c83c in graph_delete (z=0x81614e0, glist=0x0) at g_graph.c:988 #27 0x08081d6e in gobj_delete (x=0x2115, glist=0x0) at g_editor.c:61 #28 0x080576bd in glist_delete (x=0x81612f0, y=0x81614e0) at g_graph.c:108 #29 0x08054a9c in canvas_free (x=0x81612f0) at g_canvas.c:875 #30 0x0809f7e7 in pd_free (x=0x81612f0) at m_pd.c:33 #31 0x080a094d in pd_typedmess (x=0x81612f0, s=0x2115, argc=135664368, argv=0x3f800000) at m_class.c:728 #32 0x080a0816 in pd_typedmess (x=0x816c3c8, s=0x2115, argc=1, argv=0x80f92a8) at m_class.c:749 #33 0x080a3cf4 in binbuf_eval (x=0x0, target=0x816c3c8, argc=0, argv=0x0) at m_binbuf.c:574 #34 0x080ac130 in socketreceiver_read (x=0x81144c8, fd=0) at s_inter.c:540 #35 0x080adcff in sys_domicrosleep (microsec=0, pollem=1) at s_inter.c:180 #36 0x080ad398 in sys_microsleep (microsec=0) at s_inter.c:202 #37 0x080a8b2f in m_scheduler () at m_sched.c:487 #38 0x080b351b in main (argc=0, argv=0x0) at s_entry.c:27 (gdb) quit The program is running. Exit anyway? (y or n) y socket receive error: Connection reset by peer (104)
lg Gerda Mathieu Bouchard wrote:
On Tue, 13 Dec 2005, Gerda Strobl wrote:
Johannes Burström wrote: http://lists.puredata.info/pipermail/pd-list/2005-11/032513.html that he managed his problem with downgrading the libc6---do I actually have the same problem- should i also downgrade libc6 now?
I'd rather have you post a backtrace. This will enable to fix the bug instead of just pretending that it doesn't exist.
Start Pd using the gdb program by prefixing your commandline with
gdb --args
and then type the "run" command. When the crash happens, use the "where" command to find out how the crash happened. Post the report here. to leave gdb, use "quit" or Ctrl+D; if you do Ctrl+C it won't work because that's reserved for aborting the program that gdb is running.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Thomas,
i was testing rrad.eros~.pd from Frank (rradical/effects)- clicking several times on the type-toggle-and changing several times the values from the number boxes- then I want to close the patch-I get the message if I want to close the patch (y/n)-I say yes-the error message appears on the shell and the patch is not closing. I also cant open a new patch (ctrl+N).
Unfortunately I just found out that this doesn't depend on a specific patch-just opening pool-help.pd -typing on some of the connected message produces same error.
lg Gerda
Thomas Grill wrote:
Hi Gerda, can you post a simple patch using pool where this is happening? Please include detailed instructions how to reproduce the crash.
thanks, Thomas
Am 13.12.2005 um 16:05 schrieb Gerda Strobl:
Dear list, this is the output from using gdb:
(gdb) run Starting program: /usr/local/bin/pd [Thread debugging using libthread_db enabled] [New Thread -1210120512 (LWP 8469)] *** glibc detected *** double free or corruption (fasttop): 0x0816e808 ***
Program received signal SIGABRT, Aborted. [Switching to Thread -1210120512 (LWP 8469)] 0xb7e1a9e7 in raise () from /lib/tls/libc.so.6 (gdb) where #0 0xb7e1a9e7 in raise () from /lib/tls/libc.so.6 #1 0xb7e1c31b in abort () from /lib/tls/libc.so.6 #2 0xb7e51365 in __fsetlocking () from /lib/tls/libc.so.6 #3 0xb7e57a07 in malloc_usable_size () from /lib/tls/libc.so.6 #4 0xb7e57ea2 in free () from /lib/tls/libc.so.6 #5 0xb7ddd69c in flext_root_single::operator delete () from /usr/local/lib/pd/extra/pool.pd_linux #6 0xb7dd6386 in pooldir::Clear () from /usr/local/lib/pd/extra/pool.pd_linux #7 0xb7dd61db in pooldir::Reset () from /usr/local/lib/pd/extra/pool.pd_linux #8 0xb7dd62a4 in pooldir::~pooldir () from /usr/local/lib/pd/extra/pool.pd_linux #9 0xb7dd637e in pooldir::Clear () from /usr/local/lib/pd/extra/pool.pd_linux #10 0xb7dd61db in pooldir::Reset () from /usr/local/lib/pd/extra/pool.pd_linux #11 0xb7dd62a4 in pooldir::~pooldir () from /usr/local/lib/pd/extra/pool.pd_linux #12 0xb7dd40e0 in pooldata::~pooldata () from /usr/local/lib/pd/extra/pool.pd_linux #13 0xb7dcd7e2 in pool::RmvPool () from /usr/local/lib/pd/extra/pool.pd_linux #14 0xb7dcdb41 in pool::FreePool () from /usr/local/lib/pd/extra/pool.pd_linux #15 0xb7dcf2e2 in pool::~pool () from /usr/local/lib/pd/extra/pool.pd_linux #16 0xb7dd3228 in pool::__free__ () from /usr/local/lib/pd/extra/pool.pd_linux #17 0xb7dd9fd3 in flext_obj_single::obj_free () from /usr/local/lib/pd/extra/pool.pd_linux #18 0x0809f7e7 in pd_free (x=0x8178810) at m_pd.c:33 #19 0x08057709 in glist_delete (x=0x81784c8, y=0x8178810) at g_graph.c:120 #20 0x0805c83c in graph_delete (z=0x81784c8, glist=0x0) at g_graph.c:988 #21 0x08081d6e in gobj_delete (x=0x2115, glist=0x0) at g_editor.c:61 #22 0x080576bd in glist_delete (x=0x81622f8, y=0x81784c8) at g_graph.c:108 #23 0x0805c83c in graph_delete (z=0x81622f8, glist=0x0) at g_graph.c:988 #24 0x08081d6e in gobj_delete (x=0x2115, glist=0x0) at g_editor.c:61 #25 0x080576bd in glist_delete (x=0x81614e0, y=0x81622f8) at g_graph.c:108 #26 0x0805c83c in graph_delete (z=0x81614e0, glist=0x0) at g_graph.c:988 #27 0x08081d6e in gobj_delete (x=0x2115, glist=0x0) at g_editor.c:61 #28 0x080576bd in glist_delete (x=0x81612f0, y=0x81614e0) at g_graph.c:108 #29 0x08054a9c in canvas_free (x=0x81612f0) at g_canvas.c:875 #30 0x0809f7e7 in pd_free (x=0x81612f0) at m_pd.c:33 #31 0x080a094d in pd_typedmess (x=0x81612f0, s=0x2115, argc=135664368, argv=0x3f800000) at m_class.c:728 #32 0x080a0816 in pd_typedmess (x=0x816c3c8, s=0x2115, argc=1, argv=0x80f92a8) at m_class.c:749 #33 0x080a3cf4 in binbuf_eval (x=0x0, target=0x816c3c8, argc=0, argv=0x0) at m_binbuf.c:574 #34 0x080ac130 in socketreceiver_read (x=0x81144c8, fd=0) at s_inter.c:540 #35 0x080adcff in sys_domicrosleep (microsec=0, pollem=1) at s_inter.c:180 #36 0x080ad398 in sys_microsleep (microsec=0) at s_inter.c:202 #37 0x080a8b2f in m_scheduler () at m_sched.c:487 #38 0x080b351b in main (argc=0, argv=0x0) at s_entry.c:27 (gdb) quit The program is running. Exit anyway? (y or n) y socket receive error: Connection reset by peer (104)
lg Gerda Mathieu Bouchard wrote:
On Tue, 13 Dec 2005, Gerda Strobl wrote:
Johannes Burström wrote: http://lists.puredata.info/pipermail/pd-list/2005-11/032513.html that he managed his problem with downgrading the libc6---do I actually have the same problem- should i also downgrade libc6 now?
I'd rather have you post a backtrace. This will enable to fix the bug instead of just pretending that it doesn't exist.
Start Pd using the gdb program by prefixing your commandline with
gdb --args
and then type the "run" command. When the crash happens, use the "where" command to find out how the crash happened. Post the report here. to leave gdb, use "quit" or Ctrl+D; if you do Ctrl+C it won't work because that's reserved for aborting the program that gdb is running.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Gerda,
i was testing rrad.eros~.pd from Frank (rradical/effects)- clicking several times on the type-toggle-and changing several times the values from the number boxes- then I want to close the patch-I get the message if I want to close the patch (y/n)-I say yes-the error message appears on the shell and the patch is not closing. I also cant open a new patch (ctrl+N).
sorry, i don't have rradical here
Unfortunately I just found out that this doesn't depend on a specific patch-just opening pool-help.pd -typing on some of the connected message produces same error.
Could you give me some exact guidelines? You know, the problem is that here it doesn't crash - so trying around doesn't make much sense for me - it's just a waste of time.
thanks, Thomas
Hi Gerda, never mind, could you try out the pool cvs version? I think i found it.
thanks, Thomas
i was testing rrad.eros~.pd from Frank (rradical/effects)- clicking several times on the type-toggle-and changing several times the values from the number boxes- then I want to close the patch-I get the message if I want to close the patch (y/n)-I say yes-the error message appears on the shell and the patch is not closing. I also cant open a new patch (ctrl+N).
sorry, i don't have rradical here
Unfortunately I just found out that this doesn't depend on a specific patch-just opening pool-help.pd -typing on some of the connected message produces same error.
Could you give me some exact guidelines? You know, the problem is that here it doesn't crash - so trying around doesn't make much sense for me - it's just a waste of time.
thanks, Thomas
Hi Thomas,
I am using the newest cvs-sourceforge pool version. I reinstalled it again-but this doesn't change-(and I do not have any old version stored)-now I just receive either double free or corruption (fasttop)(like yesterday) or glibc detected *** corrupted double-linked list (look attached new debug report).
I am sorry but I am not able to reproduce properly, how to make that error.
(gdb) run Starting program: /usr/local/bin/pd [Thread debugging using libthread_db enabled] [New Thread -1210583360 (LWP 5276)] *** glibc detected *** corrupted double-linked list: 0xb7eb5218
Program received signal SIGABRT, Aborted. [Switching to Thread -1210583360 (LWP 5276)] 0xb7da99e7 in raise () from /lib/tls/libc.so.6 (gdb) where #0 0xb7da99e7 in raise () from /lib/tls/libc.so.6 #1 0xb7dab31b in abort () from /lib/tls/libc.so.6 #2 0xb7de0365 in __fsetlocking () from /lib/tls/libc.so.6 #3 0xb7de650c in malloc_usable_size () from /lib/tls/libc.so.6 #4 0xb7de75ab in free () from /lib/tls/libc.so.6 #5 0xb7de8901 in calloc () from /lib/tls/libc.so.6 #6 0x080a2f55 in getbytes (nbytes=0) at m_memory.c:24 #7 0xb7d6c665 in flext_root_single::operator new () from /usr/local/lib/pd/extra/pool.pd_linux #8 0xb7d65246 in pooldir::Reset () from /usr/local/lib/pd/extra/pool.pd_linux #9 0xb7d654f0 in pooldir::pooldir () from /usr/local/lib/pd/extra/pool.pd_linux #10 0xb7d63093 in pooldata::pooldata () from /usr/local/lib/pd/extra/pool.pd_linux #11 0xb7d5cc18 in pool::SetPool () from /usr/local/lib/pd/extra/pool.pd_linux #12 0xb7d5cd12 in pool::Init () from /usr/local/lib/pd/extra/pool.pd_linux ---Type <return> to continue, or q <return> to quit---quit
lg Gerda
Thomas Grill wrote:
Hi Gerda, never mind, could you try out the pool cvs version? I think i found it.
thanks, Thomas
i was testing rrad.eros~.pd from Frank (rradical/effects)- clicking several times on the type-toggle-and changing several times the values from the number boxes- then I want to close the patch-I get the message if I want to close the patch (y/n)-I say yes-the error message appears on the shell and the patch is not closing. I also cant open a new patch (ctrl+N).
sorry, i don't have rradical here
Unfortunately I just found out that this doesn't depend on a specific patch-just opening pool-help.pd -typing on some of the connected message produces same error.
Could you give me some exact guidelines? You know, the problem is that here it doesn't crash - so trying around doesn't make much sense for me - it's just a waste of time.
thanks, Thomas
Hi Gerda and Thomas,
Depending on what libraries you are using, I have heard rumours about a change of the memory allocator in debians c++ lib. Nothing concrete, but, the problem might be something that is not related to flext or pool at all, but only a bug/incoherent memory allocation thing in the standard c++ libs.
It might be worth to try it on Debian stable or testing or on ubuntu (or any other distro) and see if the problems persist.
Guenter
On Wed, 14 Dec 2005, Gerda Strobl wrote:
Hi Thomas,
I am using the newest cvs-sourceforge pool version. I reinstalled it again-but this doesn't change-(and I do not have any old version stored)-now I just receive either double free or corruption (fasttop)(like yesterday) or glibc detected *** corrupted double-linked list (look attached new debug report).
I am sorry but I am not able to reproduce properly, how to make that error.
(gdb) run Starting program: /usr/local/bin/pd [Thread debugging using libthread_db enabled] [New Thread -1210583360 (LWP 5276)] *** glibc detected *** corrupted double-linked list: 0xb7eb5218
Program received signal SIGABRT, Aborted. [Switching to Thread -1210583360 (LWP 5276)] 0xb7da99e7 in raise () from /lib/tls/libc.so.6 (gdb) where #0 0xb7da99e7 in raise () from /lib/tls/libc.so.6 #1 0xb7dab31b in abort () from /lib/tls/libc.so.6 #2 0xb7de0365 in __fsetlocking () from /lib/tls/libc.so.6 #3 0xb7de650c in malloc_usable_size () from /lib/tls/libc.so.6 #4 0xb7de75ab in free () from /lib/tls/libc.so.6 #5 0xb7de8901 in calloc () from /lib/tls/libc.so.6 #6 0x080a2f55 in getbytes (nbytes=0) at m_memory.c:24 #7 0xb7d6c665 in flext_root_single::operator new () from /usr/local/lib/pd/extra/pool.pd_linux #8 0xb7d65246 in pooldir::Reset () from /usr/local/lib/pd/extra/pool.pd_linux #9 0xb7d654f0 in pooldir::pooldir () from /usr/local/lib/pd/extra/pool.pd_linux #10 0xb7d63093 in pooldata::pooldata () from /usr/local/lib/pd/extra/pool.pd_linux #11 0xb7d5cc18 in pool::SetPool () from /usr/local/lib/pd/extra/pool.pd_linux #12 0xb7d5cd12 in pool::Init () from /usr/local/lib/pd/extra/pool.pd_linux ---Type <return> to continue, or q <return> to quit---quit
lg Gerda
Thomas Grill wrote:
Hi Gerda, never mind, could you try out the pool cvs version? I think i found it.
thanks, Thomas
i was testing rrad.eros~.pd from Frank (rradical/effects)- clicking several times on the type-toggle-and changing several times the values from the number boxes- then I want to close the patch-I get the message if I want to close the patch (y/n)-I say yes-the error message appears on the shell and the patch is not closing. I also cant open a new patch (ctrl+N).
sorry, i don't have rradical here
Unfortunately I just found out that this doesn't depend on a specific patch-just opening pool-help.pd -typing on some of the connected message produces same error.
Could you give me some exact guidelines? You know, the problem is that here it doesn't crash - so trying around doesn't make much sense for me - it's just a waste of time.
thanks, Thomas
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Günther and Gerda, it's my impression too that something is wrong with debian tested/unstable, also due to other recent problems. Anyway, yesterday's late-night bugfix indeed eliminated a double-free problem (today verified with valgrind), so Gerda, in case you are checking out from SF anonymously (that is, not as a developer), i would recommend to try again, since changes need some time to propagate inside the SF cvs.
all the best, Thomas
geiger wrote:
Hi Gerda and Thomas,
Depending on what libraries you are using, I have heard rumours about a change of the memory allocator in debians c++ lib. Nothing concrete, but, the problem might be something that is not related to flext or pool at all, but only a bug/incoherent memory allocation thing in the standard c++ libs.
It might be worth to try it on Debian stable or testing or on ubuntu (or any other distro) and see if the problems persist.
Guenter
On Wed, 14 Dec 2005, Gerda Strobl wrote:
Hi Thomas,
I am using the newest cvs-sourceforge pool version. I reinstalled it again-but this doesn't change-(and I do not have any old version stored)-now I just receive either double free or corruption (fasttop)(like yesterday) or glibc detected *** corrupted double-linked list (look attached new debug report).
I am sorry but I am not able to reproduce properly, how to make that error.
(gdb) run Starting program: /usr/local/bin/pd [Thread debugging using libthread_db enabled] [New Thread -1210583360 (LWP 5276)] *** glibc detected *** corrupted double-linked list: 0xb7eb5218
Program received signal SIGABRT, Aborted. [Switching to Thread -1210583360 (LWP 5276)] 0xb7da99e7 in raise () from /lib/tls/libc.so.6 (gdb) where #0 0xb7da99e7 in raise () from /lib/tls/libc.so.6 #1 0xb7dab31b in abort () from /lib/tls/libc.so.6 #2 0xb7de0365 in __fsetlocking () from /lib/tls/libc.so.6 #3 0xb7de650c in malloc_usable_size () from /lib/tls/libc.so.6 #4 0xb7de75ab in free () from /lib/tls/libc.so.6 #5 0xb7de8901 in calloc () from /lib/tls/libc.so.6 #6 0x080a2f55 in getbytes (nbytes=0) at m_memory.c:24 #7 0xb7d6c665 in flext_root_single::operator new () from /usr/local/lib/pd/extra/pool.pd_linux #8 0xb7d65246 in pooldir::Reset () from /usr/local/lib/pd/extra/pool.pd_linux #9 0xb7d654f0 in pooldir::pooldir () from /usr/local/lib/pd/extra/pool.pd_linux #10 0xb7d63093 in pooldata::pooldata () from /usr/local/lib/pd/extra/pool.pd_linux #11 0xb7d5cc18 in pool::SetPool () from /usr/local/lib/pd/extra/pool.pd_linux #12 0xb7d5cd12 in pool::Init () from /usr/local/lib/pd/extra/pool.pd_linux ---Type <return> to continue, or q <return> to quit---quit
lg Gerda
Thomas Grill wrote:
Hi Gerda, never mind, could you try out the pool cvs version? I think i found it.
thanks, Thomas
i was testing rrad.eros~.pd from Frank (rradical/effects)- clicking several times on the type-toggle-and changing several times the values from the number boxes- then I want to close the patch-I get the message if I want to close the patch (y/n)-I say yes-the error message appears on the shell and the patch is not closing. I also cant open a new patch (ctrl+N).
sorry, i don't have rradical here
Unfortunately I just found out that this doesn't depend on a specific patch-just opening pool-help.pd -typing on some of the connected message produces same error.
Could you give me some exact guidelines? You know, the problem is that here it doesn't crash - so trying around doesn't make much sense for me - it's just a waste of time.
thanks, Thomas
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Thomas,
today I got new pool-the double-free problem doesn't happend anymore-still pd is crashing. I am using gcc version 3.3.6 -- In the flext config-lnx-pd-gcc. txt Georg told me to try pentium-m because I dont have a pentium4 -but this doesn't change.
gerda:pool gdb pd GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1".
(gdb) run Starting program: /usr/local/bin/pd [Thread debugging using libthread_db enabled] [New Thread -1210288448 (LWP 5716)] bt
Program received signal SIGINT, Interrupt. [Switching to Thread -1210288448 (LWP 5716)] 0xb7e1e0fb in funlockfile () from /lib/tls/libc.so.6 (gdb) bt #0 0xb7e1e0fb in funlockfile () from /lib/tls/libc.so.6 #1 0xb7e053cf in vfprintf () from /lib/tls/libc.so.6 #2 0xb7e274e1 in vsnprintf () from /lib/tls/libc.so.6 #3 0x080b0577 in post (fmt=0x1 <Address 0x1 out of bounds>) at s_print.c:51 #4 0xb7db453e in flext_root_single::post () from /usr/local/lib/pd/extra/pool.pd_linux #5 0xb7dad119 in pooldir::LdDir () from /usr/local/lib/pd/extra/pool.pd_linux #6 0xb7daac7f in pooldata::LdDir () from /usr/local/lib/pd/extra/pool.pd_linux #7 0xb7da84d8 in pool::load () from /usr/local/lib/pd/extra/pool.pd_linux #8 0xb7daa4c1 in pool::flext_c_m_load () from /usr/local/lib/pd/extra/pool.pd_linux #9 0xb7db7fc7 in flext_base_single::TryMethTag () from /usr/local/lib/pd/extra/pool.pd_linux #10 0xb7db8164 in flext_base_single::FindMeth () from /usr/local/lib/pd/extra/pool.pd_linux #11 0xb7db8253 in flext_base_single::CbMethodHandler () from /usr/local/lib/pd/extra/pool.pd_linux #12 0xb7db889f in flext_base_single::cb_px_anything () from /usr/local/lib/pd/extra/pool.pd_linux #13 0x080a0816 in pd_typedmess (x=0x816c200, s=0xbfe5a37c, argc=1, argv=0x80f92e0) at m_class.c:749 #14 0x080a2167 in outlet_anything (x=0xfbad8001, s=0x81175c8, argc=1, argv=0x80f92e0) at m_obj.c:387 #15 0x080a0816 in pd_typedmess (x=0x816d2e4, s=0xbfe5a37c, argc=1, argv=0x80f92e0) at m_class.c:749 #16 0x080a3cf4 in binbuf_eval (x=0x1, target=0x816d2e4, argc=1, argv=0xbfe5de50) at m_binbuf.c:574 #17 0x0806051b in message_symbol (x=0xfbad8001, s=0x1) at g_text.c:307 #18 0x0809fb87 in pd_symbol (x=0x1, s=0xfbad8001) at m_pd.c:284 #19 0x080a206f in outlet_symbol (x=0xfbad8001, s=0x80f7b08) at m_obj.c:365 #20 0x080d6ee9 in pdsymbol_bang (x=0x1) at x_connective.c:118 #21 0x0809fb1f in pd_bang (x=0x1) at m_pd.c:269 #22 0x080a1efb in outlet_bang (x=0xfbad8001) at m_obj.c:328 #23 0x080d9371 in trigger_symbol (x=0x816d4c8, s=0x1) at x_connective.c:979 #24 0x0809fb87 in pd_symbol (x=0x1, s=0xfbad8001) at m_pd.c:284 #25 0x080a206f in outlet_symbol (x=0xfbad8001, s=0x81714f8) at m_obj.c:365 #26 0x080a0816 in pd_typedmess (x=0x816d658, s=0xbfe5a37c, argc=0, argv=0x80f92d8) at m_class.c:749 #27 0x080a2167 in outlet_anything (x=0xfbad8001, s=0x81714f8, argc=0, argv=0x80f92d8) at m_obj.c:387 #28 0x080a0816 in pd_typedmess (x=0x816d8d0, s=0xbfe5a37c, argc=1, argv=0x80f92d0) at m_class.c:749 #29 0x080a2167 in outlet_anything (x=0xfbad8001, s=0x81175c8, argc=1, argv=0x80f92d0) at m_obj.c:387 #30 0x080a0816 in pd_typedmess (x=0x816d3f8, s=0xbfe5a37c, argc=1, argv=0x80f92d0) at m_class.c:749 #31 0x080a0816 in pd_typedmess (x=0x816d460, s=0xbfe5a37c, argc=1, argv=0x80f92d0) at m_class.c:749 #32 0x080a2167 in outlet_anything (x=0xfbad8001, s=0x81175c8, argc=1, argv=0x80f92d0) at m_obj.c:387 #33 0x080d8e5f in trigger_anything (x=0x816bf70, s=0x81175c8, argc=1, argv=0x80f92d0) at x_connective.c:1001 #34 0x080a0816 in pd_typedmess (x=0x816bf70, s=0xbfe5a37c, argc=1, argv=0x80f92d0) at m_class.c:749 #35 0x080a2167 in outlet_anything (x=0xfbad8001, s=0x81175c8, argc=1, argv=0x80f92d0) at m_obj.c:387 #36 0x080a0816 in pd_typedmess (x=0x816be6c, s=0xbfe5a37c, argc=1, argv=0x80f92d0) at m_class.c:749 #37 0x080a3cf4 in binbuf_eval (x=0x1, target=0x816be6c, argc=0, argv=0x0) at m_binbuf.c:574 #38 0x08060495 in message_bang (x=0x1) at g_text.c:293 #39 0x0809fb1f in pd_bang (x=0x1) at m_pd.c:269 #40 0x080a1efb in outlet_bang (x=0xfbad8001) at m_obj.c:328 #41 0x0809fb1f in pd_bang (x=0x1) at m_pd.c:269 #42 0x0809fb1f in pd_bang (x=0x1) at m_pd.c:269 #43 0x080a1efb in outlet_bang (x=0xfbad8001) at m_obj.c:328
lg, Gerda
Thomas Grill wrote:
Hi Günther and Gerda, it's my impression too that something is wrong with debian tested/unstable, also due to other recent problems. Anyway, yesterday's late-night bugfix indeed eliminated a double-free problem (today verified with valgrind), so Gerda, in case you are checking out from SF anonymously (that is, not as a developer), i would recommend to try again, since changes need some time to propagate inside the SF cvs.
all the best, Thomas
Hi Gerda, as always it would be important to know what you are doing _exactly_ to provoke the crash. From the backtrace i can see that something is wrong with the post function, but i can't believe this is the reason as this hasn't changed for ages and is ultimately trivial. So please, a reproducible walkthrough would be highly appreciated! (including the pool data file that you are trying to load)
best greetings, Thomas
Am 20.12.2005 um 00:05 schrieb Gerda Strobl:
Hi Thomas,
today I got new pool-the double-free problem doesn't happend anymore-still pd is crashing. I am using gcc version 3.3.6 -- In the flext config-lnx-pd-gcc. txt Georg told me to try pentium-m because I dont have a pentium4 -but this doesn't change.
gerda:pool gdb pd GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1".
(gdb) run Starting program: /usr/local/bin/pd [Thread debugging using libthread_db enabled] [New Thread -1210288448 (LWP 5716)] bt
Program received signal SIGINT, Interrupt. [Switching to Thread -1210288448 (LWP 5716)] 0xb7e1e0fb in funlockfile () from /lib/tls/libc.so.6 (gdb) bt #0 0xb7e1e0fb in funlockfile () from /lib/tls/libc.so.6 #1 0xb7e053cf in vfprintf () from /lib/tls/libc.so.6 #2 0xb7e274e1 in vsnprintf () from /lib/tls/libc.so.6 #3 0x080b0577 in post (fmt=0x1 <Address 0x1 out of bounds>) at s_print.c:51 #4 0xb7db453e in flext_root_single::post () from /usr/local/lib/pd/extra/pool.pd_linux #5 0xb7dad119 in pooldir::LdDir () from /usr/local/lib/pd/extra/pool.pd_linux #6 0xb7daac7f in pooldata::LdDir () from /usr/local/lib/pd/extra/pool.pd_linux #7 0xb7da84d8 in pool::load () from /usr/local/lib/pd/extra/pool.pd_linux #8 0xb7daa4c1 in pool::flext_c_m_load () from /usr/local/lib/pd/extra/pool.pd_linux #9 0xb7db7fc7 in flext_base_single::TryMethTag () from /usr/local/lib/pd/extra/pool.pd_linux #10 0xb7db8164 in flext_base_single::FindMeth () from /usr/local/lib/pd/extra/pool.pd_linux #11 0xb7db8253 in flext_base_single::CbMethodHandler () from /usr/local/lib/pd/extra/pool.pd_linux #12 0xb7db889f in flext_base_single::cb_px_anything () from /usr/local/lib/pd/extra/pool.pd_linux #13 0x080a0816 in pd_typedmess (x=0x816c200, s=0xbfe5a37c, argc=1, argv=0x80f92e0) at m_class.c:749 #14 0x080a2167 in outlet_anything (x=0xfbad8001, s=0x81175c8, argc=1, argv=0x80f92e0) at m_obj.c:387 #15 0x080a0816 in pd_typedmess (x=0x816d2e4, s=0xbfe5a37c, argc=1, argv=0x80f92e0) at m_class.c:749 #16 0x080a3cf4 in binbuf_eval (x=0x1, target=0x816d2e4, argc=1, argv=0xbfe5de50) at m_binbuf.c:574 #17 0x0806051b in message_symbol (x=0xfbad8001, s=0x1) at g_text.c:307 #18 0x0809fb87 in pd_symbol (x=0x1, s=0xfbad8001) at m_pd.c:284 #19 0x080a206f in outlet_symbol (x=0xfbad8001, s=0x80f7b08) at m_obj.c:365 #20 0x080d6ee9 in pdsymbol_bang (x=0x1) at x_connective.c:118 #21 0x0809fb1f in pd_bang (x=0x1) at m_pd.c:269 #22 0x080a1efb in outlet_bang (x=0xfbad8001) at m_obj.c:328 #23 0x080d9371 in trigger_symbol (x=0x816d4c8, s=0x1) at x_connective.c:979 #24 0x0809fb87 in pd_symbol (x=0x1, s=0xfbad8001) at m_pd.c:284 #25 0x080a206f in outlet_symbol (x=0xfbad8001, s=0x81714f8) at m_obj.c:365 #26 0x080a0816 in pd_typedmess (x=0x816d658, s=0xbfe5a37c, argc=0, argv=0x80f92d8) at m_class.c:749 #27 0x080a2167 in outlet_anything (x=0xfbad8001, s=0x81714f8, argc=0, argv=0x80f92d8) at m_obj.c:387 #28 0x080a0816 in pd_typedmess (x=0x816d8d0, s=0xbfe5a37c, argc=1, argv=0x80f92d0) at m_class.c:749 #29 0x080a2167 in outlet_anything (x=0xfbad8001, s=0x81175c8, argc=1, argv=0x80f92d0) at m_obj.c:387 #30 0x080a0816 in pd_typedmess (x=0x816d3f8, s=0xbfe5a37c, argc=1, argv=0x80f92d0) at m_class.c:749 #31 0x080a0816 in pd_typedmess (x=0x816d460, s=0xbfe5a37c, argc=1, argv=0x80f92d0) at m_class.c:749 #32 0x080a2167 in outlet_anything (x=0xfbad8001, s=0x81175c8, argc=1, argv=0x80f92d0) at m_obj.c:387 #33 0x080d8e5f in trigger_anything (x=0x816bf70, s=0x81175c8, argc=1, argv=0x80f92d0) at x_connective.c:1001 #34 0x080a0816 in pd_typedmess (x=0x816bf70, s=0xbfe5a37c, argc=1, argv=0x80f92d0) at m_class.c:749 #35 0x080a2167 in outlet_anything (x=0xfbad8001, s=0x81175c8, argc=1, argv=0x80f92d0) at m_obj.c:387 #36 0x080a0816 in pd_typedmess (x=0x816be6c, s=0xbfe5a37c, argc=1, argv=0x80f92d0) at m_class.c:749 #37 0x080a3cf4 in binbuf_eval (x=0x1, target=0x816be6c, argc=0, argv=0x0) at m_binbuf.c:574 #38 0x08060495 in message_bang (x=0x1) at g_text.c:293 #39 0x0809fb1f in pd_bang (x=0x1) at m_pd.c:269 #40 0x080a1efb in outlet_bang (x=0xfbad8001) at m_obj.c:328 #41 0x0809fb1f in pd_bang (x=0x1) at m_pd.c:269 #42 0x0809fb1f in pd_bang (x=0x1) at m_pd.c:269 #43 0x080a1efb in outlet_bang (x=0xfbad8001) at m_obj.c:328
lg, Gerda
Thomas Grill wrote:
Hi Günther and Gerda, it's my impression too that something is wrong with debian tested/unstable, also due to other recent problems. Anyway, yesterday's late-night bugfix indeed eliminated a double-free problem (today verified with valgrind), so Gerda, in case you are checking out from SF anonymously (that is, not as a developer), i would recommend to try again, since changes need some time to propagate inside the SF cvs.
all the best, Thomas
Hallo Thomas,
attached is testpool.pd (it is from caretaker.pd /rradical/memento) As soon as I click on the save message pd tells me. pool - save: error saving data the load message leads to the described crash.
I hope that patch is useful for you.
best, Gerda
Thomas Grill wrote:
Hi Gerda, as always it would be important to know what you are doing _exactly_ to provoke the crash. From the backtrace i can see that something is wrong with the post function, but i can't believe this is the reason as this hasn't changed for ages and is ultimately trivial. So please, a reproducible walkthrough would be highly appreciated! (including the pool data file that you are trying to load)
best greetings, Thomas
#N canvas 0 0 450 300 10; #X obj 198 219 pool; #X obj 123 147 symbol $1; #X msg 199 119 pool $1; #X obj 153 89 t b s; #X msg 130 169 save $1; #X obj 282 149 symbol $1; #X msg 319 180 load $1; #X msg 337 120 pool $1; #X obj 282 90 t b s; #X obj 93 67 symbol; #X obj 174 59 symbol; #X obj 259 68 symbol; #X obj 148 33 route file save load; #X msg 92 2 save katze; #X msg 190 2 load katze; #X connect 1 0 4 0; #X connect 2 0 0 0; #X connect 3 0 1 0; #X connect 3 1 2 0; #X connect 4 0 0 0; #X connect 5 0 6 0; #X connect 6 0 0 0; #X connect 7 0 0 0; #X connect 8 0 5 0; #X connect 8 1 7 0; #X connect 9 0 1 1; #X connect 9 0 5 1; #X connect 10 0 3 0; #X connect 11 0 8 0; #X connect 12 0 9 0; #X connect 12 1 10 0; #X connect 12 2 11 0; #X connect 13 0 12 0; #X connect 14 0 12 0;
Hi Gerda, when clicking "save", your patch only sets the name of the pool used ("katze"), but not the file name... this remains empty, therefore the error message. There's no file written. (you have to send a "file whatever.txt" to route to set the file name) The same applies to loading, although i can't say why your patch actually wants to load from a file when there's no actual file given - this seems to be special for unix. Will switch to it later. Why it is crashing is yet another question that is completely out of my reach.
best greetings, Thomas
Gerda Strobl schrieb:
Hallo Thomas,
attached is testpool.pd (it is from caretaker.pd /rradical/memento) As soon as I click on the save message pd tells me. pool - save: error saving data the load message leads to the described crash.
I hope that patch is useful for you.
best, Gerda
Thomas Grill wrote:
Hi Gerda, as always it would be important to know what you are doing _exactly_ to provoke the crash. From the backtrace i can see that something is wrong with the post function, but i can't believe this is the reason as this hasn't changed for ages and is ultimately trivial. So please, a reproducible walkthrough would be highly appreciated! (including the pool data file that you are trying to load)
best greetings, Thomas
#N canvas 0 0 450 300 10; #X obj 198 219 pool; #X obj 123 147 symbol $1; #X msg 199 119 pool $1; #X obj 153 89 t b s; #X msg 130 169 save $1; #X obj 282 149 symbol $1; #X msg 319 180 load $1; #X msg 337 120 pool $1; #X obj 282 90 t b s; #X obj 93 67 symbol; #X obj 174 59 symbol; #X obj 259 68 symbol; #X obj 148 33 route file save load; #X msg 92 2 save katze; #X msg 190 2 load katze; #X connect 1 0 4 0; #X connect 2 0 0 0; #X connect 3 0 1 0; #X connect 3 1 2 0; #X connect 4 0 0 0; #X connect 5 0 6 0; #X connect 6 0 0 0; #X connect 7 0 0 0; #X connect 8 0 5 0; #X connect 8 1 7 0; #X connect 9 0 1 1; #X connect 9 0 5 1; #X connect 10 0 3 0; #X connect 11 0 8 0; #X connect 12 0 9 0; #X connect 12 1 10 0; #X connect 12 2 11 0; #X connect 13 0 12 0; #X connect 14 0 12 0;
-
geiger -
Gerda Strobl -
Mathieu Bouchard -
Thomas Grill