Menu
▾
▴
#778 [iemguts/receivecanvas] crashes on OSX when deleted
When I have [iemguts/receivecanvas] in an abstraction with no argument, then edit it to add a "1" for the depth argument, Pd crashes for me everytime using Pd-extended 0.43 2011-11-03 32-bit on Mac OS X 10.6.8. I attached the patch where it does this. Open the help patch, then open the [mouse_region] abstraction. Find the [iemguts/receivecanvas] on the middle left of the patch, and add a "1" for the depth arg. Crash!
Discussion
Anonymous
example patch to illustrate crash
abstraction to go with example patch
Confirm this for Pd-extended 0.42.5, OSX 10.5.
The depth level argument does work within an encapsulated subpatch though. Also, if you instantiate [iemguts/receivecanvas 1] or [iemguts/receivecanvas 2 ]on a freshly created window, Pd does not crash.
It seems that any patch with an encapsulated subpatch containing [iemguts/receivecanvas 1] makes Pd crash when being freed. See attached receivecanvas-test.pd.
(Pd-extended 0.42.5 and Pd-extended-0.43.1-20111102, OSX 10.5)
hmm, unable to reproduce on linux (debian wheezy/sid) with Pd-vanilla (0.43.0, 0.43.1test2, 0.43.1test3)
do you mind creating a backtrace?
here's what gdb gave me on Mac OS X 10.6.8:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x60920023
0x0002b18b in pd_typedmess ()
(gdb) bt
#0 0x0002b18b in pd_typedmess ()
#1 0x00029ebc in bindlist_anything ()
#2 0x0002b4a8 in pd_typedmess ()
#3 0x0002f8bd in binbuf_eval ()
#4 0x00038508 in socketreceiver_read ()
#5 0x00037439 in sys_domicrosleep ()
#6 0x00038041 in sys_pollgui ()
#7 0x00034a47 in m_mainloop ()
#8 0x00036aab in sys_main ()
#9 0x00001ffb in _start ()
#10 0x00001f29 in start ()
it seems that the deleted object doesn't properly unbind from the patch-receiver-symbol which is just active because you sent something to the current patch (the user-input that deletes the object)
sounds plausible. Are you asking me for more info or confirmation or just stating that?
actually it's worse than that.
unbinding is working as expected, but it's too late, as Pd already holds a reference to the receive object (which is just freed) and will then call the receive object it just deleted.
you can create the same effect by simply creating a [receive] object that with a canvas' ID as receivename (".x20342" or so) and then delete the canvas, or the [receive] object.
this example will rather seldomly occur in the wild (whereas a [receivecanvas] at depth 0 will occur more often. i'll try to come up with a simple solution...
afaict its fixed with rev.15785
Confirm that patch [receivecanvas-test] (which was accidentally not attached the first time) no longer makes pd crash on window close in Pd-0.43.1-extended-20111125-macosx105-i386.
[hcs/mouse_region] which has [iemguts/receivecanvas 1] makes Pd crash when a patch containing it is closed. For example, this is the case with [hcs/mouse_region-help]. But then, so many patches make Pd crash on window-close these days, like the 'about Pd' window. Anyway, here's the crash report (after closing [hcs/mouse_region-help]):
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000c0000051
Crashed Thread: 0
Thread 0 Crashed:
0 pd 0x0002d1db obj_nexttraverseoutlet + 107
1 pd 0x00003569 linetraverser_next + 73
2 pd 0x0000455b canvas_deletelinesforio + 59
3 pd 0x0000750d canvas_rmoutlet + 77
4 pd 0x000196ef voutlet_free + 31
5 pd 0x00029b99 pd_free + 25
6 pd 0x00006b4b glist_delete + 299
7 pd 0x0000533f canvas_free + 127
8 pd 0x00029b99 pd_free + 25
9 pd 0x00006b4b glist_delete + 299
10 pd 0x000096cc graph_delete + 44
11 pd 0x00006bc3 glist_delete + 419
12 pd 0x0000533f canvas_free + 127
13 pd 0x00029b99 pd_free + 25
14 pd 0x0002b52b pd_typedmess + 1099
15 pd 0x0002b418 pd_typedmess + 824
16 pd 0x00029e2c bindlist_anything + 60
17 pd 0x0002b418 pd_typedmess + 824
18 pd 0x0002f82d binbuf_eval + 1565
19 pd 0x000384e8 socketreceiver_read + 952
20 pd 0x00037419 sys_domicrosleep + 409
21 pd 0x00038021 sys_pollgui + 33
22 pd 0x000349b7 m_mainloop + 327
23 pd 0x00036a1b sys_main + 1675
24 pd 0x00001f6b _start + 209
25 pd 0x00001e99 start + 41
Not sure if it is related, but does reversing the commit:
http://pure-data.git.sourceforge.net/git/gitweb.cgi?p=pure-data/pure-data;a=commit;h=5c78db0883a3450e1cac727aee422ad7f4dd56eb
make your crash go away? This commit is making libpd crash when closing files via pd_free(), with a similar backtrace. I'm not sure if it is related and I'll post a new bug report if not.
I posted to the pd-dev list about this too: http://lists.puredata.info/pipermail/pd-dev/2011-11/017920.html
Cheers,
Rich
@katja: thanks for confirming
given that we now have a new backtrace which also looks suspiciously similar to other reporst (e.g. [1]) i sincerely hope that rich is right :-)
[1] https://sourceforge.net/tracker/?func=detail&aid=3437185&group_id=64325&atid=507079
this is fixed for me on Pd-extended 0.43.1 2012-01-29 32-bit running on Mac OS X 10.6.8/Intel