hello,
I made a fresh compilation of msd2D. everything works ok, except when destroying a link in msd2D, and only if Gem is loaded, i've got a pd crash with : *** glibc detected *** pd: free(): invalid pointer: 0x085d0f9c ***
i'm on ubuntu linux 10.04, flext svn, msd from svn, pd 0.43-test2 or pd 0.42.5, Gem svn or Gem 0.92-3 i start pd with : pd -noprefs -lib pd/Gem/src/Gem -open msd2D-help.pd, so nothing else is loaded except Gem and msd2D strange thing is that it work fine if gem is not loaded
it also works fine on osX, flext svn, msd from svn, pd-extended 0.42.5 RC5.
cheers Cyrille
On Wed, 8 Sep 2010, cyrille henry wrote:
I made a fresh compilation of msd2D. everything works ok, except when destroying a link in msd2D, and only if Gem is loaded, i've got a pd crash with : *** glibc detected *** pd: free(): invalid pointer: 0x085d0f9c ***
It's not necessarily the fault of either msd or Gem, and if it is, then it can be hard to figure out which one it is. Use a debugger such as valgrind, because it can trap bugs earlier in the chain reaction, quite often at the first buffer-overflow or dangling-pointer bug, rather than at the end of a chain reaction that causes glibc to bail out (or causes linux to say signal 11). With valgrind you have more of a chance of being able to produce a bug report that leads to a fix quickly.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
that issue has already been clarified - it's again a collision of globally exposed new/delete operators. It can be fixed by defining FLEXT_USE_CMEM when compiling flext and flext-based externals. gr~~~
Am 09.09.2010 um 15:32 schrieb Mathieu Bouchard:
On Wed, 8 Sep 2010, cyrille henry wrote:
I made a fresh compilation of msd2D. everything works ok, except when destroying a link in msd2D, and only if Gem is loaded, i've got a pd crash with : *** glibc detected *** pd: free(): invalid pointer: 0x085d0f9c ***
It's not necessarily the fault of either msd or Gem, and if it is, then it can be hard to figure out which one it is. Use a debugger such as valgrind, because it can trap bugs earlier in the chain reaction, quite often at the first buffer-overflow or dangling-pointer bug, rather than at the end of a chain reaction that causes glibc to bail out (or causes linux to say signal 11). With valgrind you have more of a chance of being able to produce a bug report that leads to a fix quickly.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
cyrille henry -
Mathieu Bouchard -
Thomas Grill