Hallo,
hm, that gdb output somehow looks similar to a crash, people were experiencing with loading xsample and pool at the same time. You could try to move fluid~.pd_linux somewhere, where Pd cannot see it and check, if it still crashes.
Ciao
Frank
Ken hat gesagt: // Ken wrote:
Frank Barknecht wrote:
Oops. Hm, hard to say what's happending here or where it crashes. Could you try to run Pd with a debugger? It's easy:
$ gdb /usr/bin/pd (gdb) run
< do stuff until it crashes >
(gdb) backtrace < or just "bt" >
(gdb) quit The program is running. Exit anyway? (y or n) y
It should give a hint on what could be wrong.
Ciao
ok here's the output from the debugger starting at the point where i loaded "rrad.tpl.pd". thanks again for the newbie coaching.
[New Thread -1250284624 (LWP 23349)] OSCroute object version 1.05 by Matt Wright. pd: jdl Win32 raf. OSCroute Copyright © 1999 Regents of the Univ. of California. All Rights Reserved.
- OSC-route: float arguments are not OK.
OSCroute $1 ... couldn't create *** glibc detected *** malloc(): memory corruption: 0x082cae18 ***
Program received signal SIGABRT, Aborted. [Switching to Thread -1208121664 (LWP 23342)] 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x00b5f7d5 in raise () from /lib/tls/libc.so.6 #2 0x00b61149 in abort () from /lib/tls/libc.so.6 #3 0x00b9327a in __libc_message () from /lib/tls/libc.so.6 #4 0x00b9a49c in _int_malloc () from /lib/tls/libc.so.6 #5 0x00b9bc76 in calloc () from /lib/tls/libc.so.6 #6 0x0809f77e in getbytes () #7 0x00000001 in ?? () #8 0x00000034 in ?? () #9 0xb71cad56 in flext_root_single::operator new () from /usr/lib/pd/extra/fluid~.pd_linux #10 0xb4f8d8f4 in flext_base_single::ItemCont::Resize () from /usr/local/lib/pd/extra/pool.pd_linux #11 0xb4f8d9f5 in flext_base_single::ItemCont::Add () from /usr/local/lib/pd/extra/pool.pd_linux #12 0xb4f8e250 in flext_base_single::AddMethod () from /usr/local/lib/pd/extra/pool.pd_linux #13 0xb4f867be in flext_base_single::Setup () from /usr/local/lib/pd/extra/pool.pd_linux #14 0xb4f7fafa in pool::__setup__ () from /usr/local/lib/pd/extra/pool.pd_linux #15 0xb4f88151 in flext_obj_single::obj_add () from /usr/local/lib/pd/extra/pool.pd_linux #16 0xb4f795ca in pool_setup () from /usr/local/lib/pd/extra/pool.pd_linux #17 0x080ac39e in sys_load_lib () #18 0xbfffb8fc in ?? () #19 0x000003e8 in ?? () #20 0x00000001 in ?? () #21 0x00c5f800 in __malloc_initialize_hook () from /lib/tls/libc.so.6 #22 0xbfffb944 in ?? () #23 0x00c523e1 in __libc_ptyname1 () from /lib/tls/libc.so.6 #24 0x00000000 in ?? () (gdb)
hm, that gdb output somehow looks similar to a crash, people were experiencing with loading xsample and pool at the same time. You could try to move fluid~.pd_linux somewhere, where Pd cannot see it and check, if it still crashes.
hmmm, seems like at times i'll have to figure out how to make things really user-proof. all the best, Thomas
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
hm, that gdb output somehow looks similar to a crash, people were experiencing with loading xsample and pool at the same time. You could try to move fluid~.pd_linux somewhere, where Pd cannot see it and check, if it still crashes.
hmmm, seems like at times i'll have to figure out how to make things really user-proof.
Is this somehow related to the FLEXT_GLOBAL_NEW (or similar) define? Should I maybe undef this in the fluid~-source or build system?
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hi Frank,
hm, that gdb output somehow looks similar to a crash, people were experiencing with loading xsample and pool at the same time. You could try to move fluid~.pd_linux somewhere, where Pd cannot see it and check, if it still crashes.
hmmm, seems like at times i'll have to figure out how to make things really user-proof.
Is this somehow related to the FLEXT_GLOBAL_NEW (or similar) define? Should I maybe undef this in the fluid~-source or build system?
the bad thing on linux seems to be that one function symbol (like the global operator new in this case) must be unique in a process, or, if there are different versions, it's not forseeable (for me) which one is taken. In this sense FLEXT_NOGLOBAL_NEW needs to be defined for both the flext build and the external, or not be defined for both. It seems like, to avoid this problems in the future, the best thing would be to simply ignore the PD memory reservation scheme (getbytes) and (for linux at least) assume FLEXT_NOGLOBAL_NEW generally, because getbytes simply maps to the C standard library anyway.
On the other hand all problems i lately inspected on user's machines have been due to misconfigured flext/buildsys/config-pd-linux-gcc.txt files or old versions of some headers and/or libraries or due to old versions in general, or combinations of the above.
Please tell me your solution, once it's working
all the best, Thomas
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
On the other hand all problems i lately inspected on user's machines have been due to misconfigured flext/buildsys/config-pd-linux-gcc.txt files or old versions of some headers and/or libraries or due to old versions in general, or combinations of the above.
Well, Ken's problem could indeed be a version conflict. As this problem turned up mostly for Debian system: Debian testing/unstable underwent a phase of quite a big library/libc update, which seemed to affect lots of packages and is one of the reasons, why I'm currently hesitant to change anything important in that area in my system until the dust has settled. However from what I hear, the dust is beginning to settle currently, so that might be good news.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-
Frank Barknecht -
Thomas Grill