[PD-dev] my_numbox_draw_update and other saving crash

[Luke Iannini]

Here's another from tonight... this time from hitting "Escape", which
I have mapped to switch off some spigots in my patch.

On Fri, Dec 12, 2008 at 1:19 AM, Luke Iannini <lukexipd at gmail.com> wrote:
> Hallo,
> I'm writing to ask for help tracking down some very bad crash bugs
> that have been biting me daily for a good year (sigh, why does it take
> me so long to confront such issues : ) ).
>
> The crash always occurs when I am saving an instance of an abstraction
> containing a "Number2" number box, and I believe this portion is
> always the same:
>
> Thread 0 Crashed:
> 0   pd                                  0x00006369 glist_getcanvas + 10
> (g_graph.c:187)
> 1   pd                                  0x00002b25 glist_isvisible + 30
> (g_canvas.c:854)
> 2   pd                                  0x0002cc7d my_numbox_draw_update +
> 28 (g_numbox.c:138)
> 3   pd                                  0x0004447c sys_pollgui + 179 (s_inter.c:759)
> 4   pd                                  0x00041728 m_scheduler + 348 (m_sched.c:468)
> 5   pd                                  0x00043770 sys_main + 1524 (s_main.c:320)
> 6   pd                                  0x000021ae _start + 216
> 7   pd                                  0x000020d5 start + 41
>
> All of my abstractions tend to have many instances, so it seems to be
> during the reload process that the crash occurs.  As far as I can
> tell, the patch always does save succesfully before the crash.  I've
> tried recreating the conditions with a stripped down GOP abstraction
> containing a numbox2 and saving it, but haven't succeeded yet.
>
> And, here's another one.  I didn't record any specific factors for
> this one, but I'll try to if I see it again.
> Thread 0 Crashed:
> 0   pd                                  0x00039c9d pd_typedmess + 109 (m_class.c:695)
> 1   pd                                  0x00039f64 pd_typedmess + 820 (m_class.c:805)
> 2   pd                                  0x00038c0a bindlist_anything + 49
> (m_pd.c:107)
> 3   pd                                  0x00039f64 pd_typedmess + 820 (m_class.c:805)
> 4   pd                                  0x0003d7df binbuf_eval + 1043
> (m_binbuf.c:677)
> 5   pd                                  0x000448ca socketreceiver_read +
> 1016 (s_inter.c:553)
> 6   pd                                  0x00043983 sys_domicrosleep + 367
> (s_inter.c:193)
> 7   pd                                  0x000443e3 sys_pollgui + 26 (s_inter.c:840)
> 8   pd                                  0x00041728 m_scheduler + 348 (m_sched.c:468)
> 9   pd                                  0x00043770 sys_main + 1524 (s_main.c:320)
> 10  pd                                  0x000021ae _start + 216
> 11  pd                                  0x000020d5 start + 41
>
> I've had a pretty rough time with my admittedly large abstraction
> suite.  I haven't read anyone else complaining so I guess I'm alone in
> trying to make a Cubase (circa 1990)-scale program in Pd, but it does
> work, wonderfully so (with shockingly low CPU utilization), when I'm
> not running into crashes, so I'd rather not be told "don't try to make
> large applications in Pd : )" since the issues seem to be on the
> loading (very slow) and saving (very unreliable) side of things rather
> than the actual operational side.
>
> This is running Pd-extended 0.40 on Intel OS X.
>
> I attached the full crash logs.
>
> Best
> Luke
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Another_crash.txt
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20081212/92800163/attachment.txt>