Public bug reported:
Binary package hint: puredata
Steps to reproduce hang or crash
* Open PD
* New Patch
* Create subpatch [pd test]
* Add a graphical control to test
* Turn "graph on parent" on.
* Apply this.
* Set the parent canvas size - note the parent canvas does NOT update.
* Ok this
* Drag the control into view in the subpatch (the red rectangle)
* Ctrl- C, Ctrl-V the parent reference to the subpatch
* Delete the original subpatch reference.
* You will now no longer be able to interact with the patches through either an
outright crash, or a hang with CPU at 100% and Pd canvases not responding
When it hangs, the menu still interacts, but most options do nothing.
File->Open presents a dialog which will not actually open anything
anyway. You can only close via the main PD window if it has hung like
this. No open individual patches can close. When you close via the main
window - note that the UI all closes, but the pd process lives on
sucking up 100% CPU in background now. You would have to kill it.
Attaching gdb to this process when hung after closing gives the following
backtrace (where "pd test" is the subpatch):
#0 glist_noselect (x=0x823e6f0) at g_editor.c:222
#1 0x08058565 in canvas_free (x=0x823e6f0) at g_canvas.c:873
#2 0x080a5197 in pd_free (x=0x823e6f0) at m_pd.c:29
#3 0x0805ae1b in glist_delete (x=<value optimized out>, y=0x823e6f0)
at g_graph.c:120
#4 0x0805f386 in text_setto (x=0x823e6f0, glist=0x8233ed8,
buf=0x823e7d8 "pd test ", bufsize=0) at g_text.c:1293
#5 0x080841a1 in glist_deselect (x=0x8233ed8, y=0x823e6f0) at g_editor.c:207
#6 0x08088fde in canvas_doclick (x=0x8233ed8, xpos=72, ypos=112, which=1,
mod=0, doit=1) at g_editor.c:222
#7 0x080898f7 in canvas_mousedown (x=0x8233ed8, xpos=72, ypos=112, which=1,
mod=0) at g_editor.c:1252
#8 0x080a607f in pd_typedmess (x=0x8233ed8, s=0x8227c40, argc=4,
argv=0x8117f88) at m_class.c:728
#9 0x080a5ce6 in pd_typedmess (x=0x8233e20, s=0x8227c40,
argc=<value optimized out>, argv=0x8117f88) at m_class.c:749
#10 0x080aa533 in binbuf_eval (x=0x82334f0, target=0x8233e20, argc=0, argv=0x0)
at m_binbuf.c:574
#11 0x080b7883 in socketreceiver_read (x=0x8233510, fd=4) at s_inter.c:540
#12 0x080b4c79 in sys_domicrosleep (microsec=<value optimized out>,
pollem=<value optimized out>) at s_inter.c:180
#13 0x080b5ca7 in sys_pollgui () at s_inter.c:823
#14 0x080b1917 in m_scheduler () at m_sched.c:466
#15 0x080b485a in sys_main (argc=1, argv=0xbfdbaa04) at s_main.c:292
#16 0x080bda7f in main (argc=Cannot access memory at address 0x0
) at s_entry.c:27
Looking at glist_noselect it is in g_editor.c and has the following while loop:
while (x->gl_editor->e_selection)
glist_deselect(x, x->gl_editor->e_selection->sel_what);
Looking at glist_deselect, it will exit if a static var "reenter" is 1 -
probably to deal with recursion issues. After checking it, it will then set it
to 1, only zeroing it when it reaches the end of the glist_deselect function.
Stepping into glist_deselect, the reenter var is set to 1. If you look
at the stack trace, #5 is the first call to this. This calls text_setto,
which if it is not the special case, starts by destroying the old text
with glist_delete and creating a new one. This leads to it calling
pd_free, which calls the canvas_free with the same x, and then the
deselect is called again with the same object.
** Affects: puredata (Ubuntu)
Importance: Undecided
Status: Unconfirmed
--
Hang or Crash when deleting one of multiple references to a subpatch
https://launchpad.net/bugs/84522
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
