Hi,
I want to close the GEM window using a key read with [gemkeyname] however this crashes Pd. Using attached little patch, I get the following GDB backtrace:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210861888 (LWP 615)] clock_set (x=0x0, setticks=1) at m_sched.c:55 55 if (x->c_settime >= 0) (gdb) bt #0 clock_set (x=0x0, setticks=1) at m_sched.c:55 #1 0xb79af312 in GemMan::getConstWindowInfo () from /usr/lib/pd/extra/Gem.pd_linux #2 0x080aa8b6 in m_scheduler () at m_sched.c:355 #3 0x080b53fb in main (argc=12576, argv=0x3120) at s_entry.c:27
Clicking the destroy-message box by hand doesn't crash. Any ideas?
Ciao
Frank Barknecht wrote:
Hi,
I want to close the GEM window using a key read with [gemkeyname] however this crashes Pd. Using attached little patch, I get the following GDB backtrace:
[...]
Clicking the destroy-message box by hand doesn't crash. Any ideas?
this used to be "just normal". image what happens: you press a key; [gemkeyname] binds itself to the window and reads all events that occured since the last time; a message is sent to the outlet; the gemkeyname-function is pushed to the stack; the message triggers window destruction; window is destroyed and invalid; the gemkeyname-function is popped from the stack and continues to run with a now invalid window -> references to this window crash pd.
when you click on the [destroy( message manually, then the function stack is clean.
2 ways to fix it: decouple the gemkeyname-message from the [destroy( message by a simple [del 0] in current CVS this should be fixed (but i often find that i think i have checked in changes and actually have not....)
mfg,.adr. IOhannes
PS: i noticed a very similar thing with plain pd just recently: if you have an object which emits a message which is then sent out of the canvas (abstraction, subpatch) and which is used to clear the canvas immediately (destroying the object), this crashes pd. decoupling the message sending from the object destruction saves your live. however, i am not sure, whether this *should* be fixed: it is more a bug in the patch than within pd itself.
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
this used to be "just normal". image what happens: you press a key; [gemkeyname] binds itself to the window and reads all events that occured since the last time; a message is sent to the outlet; the gemkeyname-function is pushed to the stack; the message triggers window destruction; window is destroyed and invalid; the gemkeyname-function is popped from the stack and continues to run with a now invalid window -> references to this window crash pd.
when you click on the [destroy( message manually, then the function stack is clean.
2 ways to fix it: decouple the gemkeyname-message from the [destroy( message by a simple [del 0]
Thanks for the explanation, I'll use a [del] then, which works fine.
Ciao
-
Frank Barknecht -
IOhannes m zmoelnig