#678 reopening simple GOP patch crashes Pd everytime

[Hans-Christoph Steiner]

Using today's HEAD from pure-data git built and run on Mac OS X 10.5.8/Intel, opening, closing, then reopening the attached patch causes Pd to crash every time. The patch in question is from Gem/examples/06.particle/01.simple.pd. You do not need Gem to make this happen, but having Gem doesn't seem to affect the crash.

Here are the steps to reproduce:

0. launch pd
1. open gop-reopen-crash.pd
2. cloes gop-reopen-crash.pd
3. open gop-reopen-crash.pd
4. close gop-reopen-crash.pd
5. CRASH!

I get this dump in the terminal:

pd(19360,0xa0905720) malloc: *** error for object 0x230002: Non-aligned pointer being freed
*** set a breakpoint in malloc_error_break to debug
pd(19360,0xa0905720) malloc: *** error for object 0x2313b0: double free
*** set a breakpoint in malloc_error_break to debug
pd(19360,0xa0905720) malloc: *** error for object 0x231670: double free
*** set a breakpoint in malloc_error_break to debug
pd(19360,0xa0905720) malloc: *** error for object 0x231430: double free
*** set a breakpoint in malloc_error_break to debug
pd(19360,0xa0905720) malloc: *** error for object 0x230970: double free
*** set a breakpoint in malloc_error_break to debug
Bus error

And I attached a full crash dump from the Mac OS X Crash Reporter.

[Hans-Christoph Steiner]

patch to cause the crash

[Hans-Christoph Steiner]

crash dump from Mac OS X Crash Reporter

[Hans-Christoph Steiner]

I forgot to add, it seems the patch is always occuring in canvas_free(), so it seems like its a double free of something related to GOP.

[Hans-Christoph Steiner]

Ico's seems to have mulled this bug or something similar quite a bit, I just found this in the pd-l2ork source, in pd/src/m_pd.c:

+ /* here we make sure we do not create objects at the same memory address as before
+ to avoid double-entry bug that is invoked when this happens. why? no idea...
+ tcl/tk definitely sends only one command via socket, yet it is activated multiple
+ times inside c code. perhaps class_addmethod is never cleaned out (although this
+ makes no sense either as we use calloc which should zero everything out, yet even
+ that is not entirely guarranteed)
+
+ we do this by comparing the newly allocated address with preexisting list of
+ canvases that were created in the past.
+
+ if a duplicate is triggered, we deallocate memory and reallocate it assigning
+ a random additional amount of memory and then resize allocation to the original
+ size
+
+ duplicate: -1 initial state
+ 0 all is ok
+ 1 found a duplicate

[Hans-Christoph Steiner]

ico's fix for something that seems similar

[Miller Puckette]

I couldn't recreate this on my 10.4 machine... will try to find 10.5 somewhere at work
next week.

[Hans-Christoph Steiner]

I reconfirmed, it happens to be everytime on Mac OS X 10.5.8/Intel, I tried with three different Tcl/Tk versions, including an X11 based one. It did not happen on my Debian/squeeze box.