hi,
all have been reproduced in 0.37-1test6
Krzysztof
BUG #17 crash when receiver breaks a tcp connection from netsend to netreceive
If there is a tcp connection established from netsend to netreceive, and the receiving end quits (or crashes), then the sender tends to crash when trying to talk to the other end.
Plain closing of the receiving patch may crash both ends, e.g. if the patch is reopened (this might need another PR).
BUG #18 [makefilename <%s-pattern>] crash
Crash when sending a float to [makefilename <%s-pattern>].
BUG #19 'menuclose' crash
Crash when sending 'pd-<name>.pd menuclose', if more than one <name>.pd is open.
BUG #20 setting the gop flag may lead to crashes
Crash when opening a gop after transforming it from a non-gop in certain ways (details in How-To-Repeat field).
BUG #21 self-destruction crash
Crash if sending to a target causes it to perform self-destruction.
BUG #22 message 'receive' to iemguis broken, causing crashes
Message 'receive' to iemguis is broken. This has two consequences:
1. since the new target is not bound, the object cannot be reached remotely anymore;
2. since the old target is never unbound, sending to that target after object's destruction (patch closing, etc.) crashes Pd.
The immediate reason is that in iemgui_receive(), the condition
if(strcmp(rcv->s_name, iemgui->x_rcv->s_name))
is always false due to the previous
iemgui->x_rcv = rcv = canvas_realizedollar(iemgui->x_glist, rcv);
Not sure, whether this message should be patched or removed, though -- self-rebinding is not yet safe in Pd.
Hallo,
I also have a crash to report, but didn't look for a fix yet. :( It shouldn't be to difficult, though.
[makefilename %s-something] crashes Pd if a float is sent to the inlet.
ciao
Hi Krzysztof,
Thanks for all the reports... I can fix #17 I think (just ignore SIGPIPE; don't know why I wanted to exit from it in the first place.)
Where do I go to reproduce #20 (GOP crash)? I should fix that one.
I think about the self-closing and hhe IEMGUI "receive" (which are really the same underlying problem) I have to do something complicated and shouldn't try it for 0.37-1 lest I introduce more problems than I fix. Also, I want to redesign makefilename to take multiple arguments and in doing so will fix the float bug. (both of these for 0.38...)
cheers Miller
On Sat, Feb 07, 2004 at 04:32:19PM +0100, Krzysztof Czaja wrote:
hi,
all have been reproduced in 0.37-1test6
Krzysztof
BUG #17 crash when receiver breaks a tcp connection from netsend to netreceive
If there is a tcp connection established from netsend to netreceive, and the receiving end quits (or crashes), then the sender tends to crash when trying to talk to the other end.
Plain closing of the receiving patch may crash both ends, e.g. if the patch is reopened (this might need another PR).
BUG #18 [makefilename <%s-pattern>] crash
Crash when sending a float to [makefilename <%s-pattern>].
BUG #19 'menuclose' crash
Crash when sending 'pd-<name>.pd menuclose', if more than one <name>.pd is open.
BUG #20 setting the gop flag may lead to crashes
Crash when opening a gop after transforming it from a non-gop in certain ways (details in How-To-Repeat field).
BUG #21 self-destruction crash
Crash if sending to a target causes it to perform self-destruction.
BUG #22 message 'receive' to iemguis broken, causing crashes
Message 'receive' to iemguis is broken. This has two consequences:
- since the new target is not bound, the object cannot be reached
remotely anymore;
- since the old target is never unbound, sending to that target
after object's destruction (patch closing, etc.) crashes Pd.
The immediate reason is that in iemgui_receive(), the condition
if(strcmp(rcv->s_name, iemgui->x_rcv->s_name))
is always false due to the previous
iemgui->x_rcv = rcv = canvas_realizedollar(iemgui->x_glist, rcv);
Not sure, whether this message should be patched or removed, though -- self-rebinding is not yet safe in Pd.
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
hi Miller,
Miller Puckette wrote: ...
Where do I go to reproduce #20 (GOP crash)? I should fix that one.
Yes, I did not include the 'How-To-Repeat' field in the bulk query (see it below, in the p.s.).
I think about the self-closing and hhe IEMGUI "receive" (which are really the same underlying problem) I have to do something complicated and shouldn't try it for 0.37-1 lest I introduce more problems than I fix. Also,
I think #22 is different, and quite obvious. There is nothing fundamental in iemgui_receive()'s refusal of rebinding -- it is a plain, local bug.
The reason of the crash is that after an object bound to 'old' has been sent "receive new", the object is still bound to 'old', but, since the 'x_rcv' field now points to 'new', the object's destructor tries to unbind 'new', not 'old' (there is a warning). After that, the bindlist's 'b_pd' pointer (or bindelem's 'e_who') dangles, waiting for its prey to fall in the 'old' trap.
Krzysztof
Synopsis: setting the gop flag may lead to crashes
Description:
Crash when opening a gop after transforming it from a non-gop in certain ways (details in How-To-Repeat field).
How-To-Repeat:
Make sure the subpatch to be transformed from non-gop to gop contains at least one text object. Then, either:
1. after opening the props dialog of the subpatch, first close the subpatch window, then set the gop flag in the dialog, and finally, open the transformed subpatch again; or:
2. transform the subpatch (when it has its window closed) by sending it the 'coords' message, then open it.
-
Frank Barknecht -
Krzysztof Czaja -
Miller Puckette -
Yves Degoyon