Hi,
I experience a strange crash with current [pool], checked out some minutes ago and flext checked out then as well. I'm using Miller's Pd 0.38 HEAD from CVS, that is, I'm not using the "devel_X" branch.
_The crash_
If I create a simple patch:
[set x y( | [pool]
and if I then bang [set x y( *twice* Pd immediatly crashes. Under gdb, this is in the backtrace:
pool 0.2.1pre - hierarchical storage object, (C)2002-2005 Thomas Grill
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1209710912 (LWP 13024)] 0xb7636105 in poolval::Set () from /usr/lib/pd/extra/pool.pd_linux (gdb) bt #0 0xb7636105 in poolval::Set () from /usr/lib/pd/extra/pool.pd_linux #1 0xb7636a3c in pooldir::SetVal () from /usr/lib/pd/extra/pool.pd_linux #2 0xb7630153 in pool::set () from /usr/lib/pd/extra/pool.pd_linux #3 0xb7633b15 in pool::flext_c_m_set () from /usr/lib/pd/extra/pool.pd_linux #4 0xb76bf518 in flext_base_single::TryMethTag () from /usr/lib/pd/extra/xsample.pd_linux #5 0xb76bf6d9 in flext_base_single::FindMeth () from /usr/lib/pd/extra/xsample.pd_linux #6 0xb76424de in flext_base_single::CbMethodHandler () from /usr/lib/pd/extra/pool.pd_linux #7 0xb76bfbcf in flext_base_single::cb_px_anything () from /usr/lib/pd/extra/xsample.pd_linux #8 0x0809b756 in pd_typedmess (x=0x82613d0, s=0x1, argc=2, argv=0x80f2b30) at m_class.c:749 #9 0x0809d037 in outlet_anything (x=0x8261f14, s=0x8203b88, argc=2, argv=0x80f2b30) at m_obj.c:380 #10 0x0809b756 in pd_typedmess (x=0x82614dc, s=0x1, argc=2, argv=0x80f2b30) at m_class.c:749 #11 0x0809ebc4 in binbuf_eval (x=0x8263024, target=0x82614dc, argc=1, argv=0xbfffd698) at m_binbuf.c:574 #12 0x08061dec in text_click (z=0x82614c0, glist=0x825ed30, xpix=235, ypix=136, shift=136713436, alt=-1073752424, dbl=0, doit=0) at g_text.c:300 #13 0x08079745 in canvas_doclick (x=0x825ed30, xpos=235, ypos=136, which=1, mod=0, doit=1) at g_editor.c:742 #14 0x0807ddeb in canvas_mousedown (x=0x8263024, xpos=-7.73854845e-06, ypos=-7.73854845e-06, which=-7.73854845e-06, mod=-7.73854845e-06) at g_editor.c:1172 #15 0x0809b88d in pd_typedmess (x=0x825ed30, s=0x1, argc=136703280, argv=0x436b0000) at m_class.c:728 #16 0x0809b756 in pd_typedmess (x=0x82148d0, s=0x1, argc=4, argv=0x80f2b08) at m_class.c:749 #17 0x0809ebc4 in binbuf_eval (x=0x8263024, target=0x82148d0, argc=0, argv=0x0) at m_binbuf.c:574 #18 0x080a6fc0 in socketreceiver_read (x=0x82137f8, fd=0) at s_inter.c:509 #19 0x080a8b5f in sys_domicrosleep (microsec=136720420, pollem=1) at s_inter.c:169 #20 0x080a879e in sys_pollgui () at s_inter.c:787 #21 0x080a3828 in m_scheduler () at m_sched.c:456 #22 0x080ad6db in main (argc=136720420, argv=0x8263024) at s_entry.c:27 (gdb)
Does it ring a bell with someone?
Ciao
Hi Frank, i can reproduce the crash, but only on linux, which is strange and which is giving me a hard time (seems like i'll slowly have to learn to debug with gdb, sigh)
many thanks, Thomas
Am 12.04.2005 um 22:16 schrieb Frank Barknecht:
Hi,
I experience a strange crash with current [pool], checked out some minutes ago and flext checked out then as well. I'm using Miller's Pd 0.38 HEAD from CVS, that is, I'm not using the "devel_X" branch.
_The crash_
If I create a simple patch:
[set x y( | [pool]
and if I then bang [set x y( *twice* Pd immediatly crashes. Under gdb, this is in the backtrace:
pool 0.2.1pre - hierarchical storage object, (C)2002-2005 Thomas Grill
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1209710912 (LWP 13024)] 0xb7636105 in poolval::Set () from /usr/lib/pd/extra/pool.pd_linux (gdb) bt #0 0xb7636105 in poolval::Set () from /usr/lib/pd/extra/pool.pd_linux #1 0xb7636a3c in pooldir::SetVal () from /usr/lib/pd/extra/pool.pd_linux #2 0xb7630153 in pool::set () from /usr/lib/pd/extra/pool.pd_linux #3 0xb7633b15 in pool::flext_c_m_set () from /usr/lib/pd/extra/pool.pd_linux #4 0xb76bf518 in flext_base_single::TryMethTag () from /usr/lib/pd/extra/xsample.pd_linux #5 0xb76bf6d9 in flext_base_single::FindMeth () from /usr/lib/pd/extra/xsample.pd_linux #6 0xb76424de in flext_base_single::CbMethodHandler () from /usr/lib/pd/extra/pool.pd_linux #7 0xb76bfbcf in flext_base_single::cb_px_anything () from /usr/lib/pd/extra/xsample.pd_linux #8 0x0809b756 in pd_typedmess (x=0x82613d0, s=0x1, argc=2, argv=0x80f2b30) at m_class.c:749 #9 0x0809d037 in outlet_anything (x=0x8261f14, s=0x8203b88, argc=2, argv=0x80f2b30) at m_obj.c:380 #10 0x0809b756 in pd_typedmess (x=0x82614dc, s=0x1, argc=2, argv=0x80f2b30) at m_class.c:749 #11 0x0809ebc4 in binbuf_eval (x=0x8263024, target=0x82614dc, argc=1, argv=0xbfffd698) at m_binbuf.c:574 #12 0x08061dec in text_click (z=0x82614c0, glist=0x825ed30, xpix=235, ypix=136, shift=136713436, alt=-1073752424, dbl=0, doit=0) at g_text.c:300 #13 0x08079745 in canvas_doclick (x=0x825ed30, xpos=235, ypos=136, which=1, mod=0, doit=1) at g_editor.c:742 #14 0x0807ddeb in canvas_mousedown (x=0x8263024, xpos=-7.73854845e-06, ypos=-7.73854845e-06, which=-7.73854845e-06, mod=-7.73854845e-06) at g_editor.c:1172 #15 0x0809b88d in pd_typedmess (x=0x825ed30, s=0x1, argc=136703280, argv=0x436b0000) at m_class.c:728 #16 0x0809b756 in pd_typedmess (x=0x82148d0, s=0x1, argc=4, argv=0x80f2b08) at m_class.c:749 #17 0x0809ebc4 in binbuf_eval (x=0x8263024, target=0x82148d0, argc=0, argv=0x0) at m_binbuf.c:574 #18 0x080a6fc0 in socketreceiver_read (x=0x82137f8, fd=0) at s_inter.c:509 #19 0x080a8b5f in sys_domicrosleep (microsec=136720420, pollem=1) at s_inter.c:169 #20 0x080a879e in sys_pollgui () at s_inter.c:787 #21 0x080a3828 in m_scheduler () at m_sched.c:456 #22 0x080ad6db in main (argc=136720420, argv=0x8263024) at s_entry.c:27 (gdb)
Does it ring a bell with someone?
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
I experience a strange crash with current [pool], checked out some minutes ago and flext checked out then as well. I'm using Miller's Pd 0.38 HEAD from CVS, that is, I'm not using the "devel_X" branch.
_The crash_
If I create a simple patch:
[set x y( | [pool]
and if I then bang [set x y( *twice* Pd immediatly crashes. Under gdb, this is in the backtrace:
Hm, somehow this crash doesn't occur anymore. Things I did: I renamed the old /usr/lib/pd/flext directory to some other name, and I ran "ldconfig" (all on Linux). Now I can run the set-test without problems.
Sorry for interrupting...
Ciao
I still have the crash with the statically linked version, but not with the shared one. It looks like a version mismatch somewhere, but i can't spot the source of the problem. Is your pool version static or dynamic?
best, Thomas
Frank Barknecht wrote:
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
I experience a strange crash with current [pool], checked out some minutes ago and flext checked out then as well. I'm using Miller's Pd 0.38 HEAD from CVS, that is, I'm not using the "devel_X" branch.
_The crash_
If I create a simple patch:
[set x y( | [pool]
and if I then bang [set x y( *twice* Pd immediatly crashes. Under gdb, this is in the backtrace:
Hm, somehow this crash doesn't occur anymore. Things I did: I renamed the old /usr/lib/pd/flext directory to some other name, and I ran "ldconfig" (all on Linux). Now I can run the set-test without problems.
Sorry for interrupting...
Ciao
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
I still have the crash with the statically linked version, but not with the shared one. It looks like a version mismatch somewhere, but i can't spot the source of the problem. Is your pool version static or dynamic?
Good question: I just ran "flext-build.sh pd gcc build", I'm not sure, what this is intended to build and where to specify shared vs. dynamic. I still need to do some reading of your new (to me) build system.
Here's some more info about the file:
$ du -sch /usr/lib/pd/extra/pool.pd_linux 180K /usr/lib/pd/extra/pool.pd_linux 180K total $ ldd /usr/lib/pd/extra/pool.pd_linux libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb7eff000) libm.so.6 => /lib/tls/libm.so.6 (0xb7edd000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7ed3000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7ec4000) libc.so.6 => /lib/tls/libc.so.6 (0xb7d90000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
which, flext-wise looks static.
Ciao
Is your pool version static or dynamic?
Good question: I just ran "flext-build.sh pd gcc build", I'm not sure, what this is intended to build and where to specify shared vs. dynamic. I still need to do some reading of your new (to me) build system.
Yes, it's static. This is still the default on linux at the moment since the versioning system of the shared libraries has been introduced only some days ago. To build a shared version you would run "flext-build.sh pd gcc build-release-shared"
best greetings, Thomas
-
Frank Barknecht -
Thomas Grill