On Thu, Jun 18, 2020 at 8:55 PM Ivica Ico Bukvic <ico at vt.edu> wrote:
>
> I am not even sure if we need to check for argc... That said, the
> warning for some reason is not being triggered.
Please run purr-data/scripts/regression_test.pd to make sure this
isn't breaking anything.
>
> Lastly, please note that creating a patch in purr-data and saving it
> still results in the legacy <command>, f <num>; format for describing
> the custom width of an object.
Ooh, we need to change that.
We should open both formats and only save the sane one.
-Jonathan
>
> Best,
>
> Ico
>
> On 6/18/2020 8:53 PM, Ivica Ico Bukvic wrote:
> > How about simply changing the following inside canvas_f:
> >
> > if (pd_class(last_typedmess_pd) == canvas_class &&
> > (t_canvas *)last_typedmess_pd == x &&
> > last_typedmess == gensym("restore"))
> >
> > to:
> >
> > if (s == gensym("f") && argc >= 1)
> >
> > Seems to have fixed the segfault on Linux and Windows.
> >
> > Best,
> >
> > Ico
> >
> > On 6/18/2020 4:53 PM, Jonathan Wilkes wrote:
> >> On Thu, Jun 18, 2020 at 4:29 PM Ivica Ico Bukvic <ico at vt.edu> wrote:
> >>> It's by far the most SNAFU'd implementation of a for loop I've ever
> >>> seen. So much so, I am not even sure what it exactly does:
> >>>
> >>> --> for (g = x->gl_list; g2 = g->g_next; g = g2)
> >>> ;
> >> This is all about that inane ", f $value" syntax that Miller wrote,
> >> didn't
> >> test, and then got changed in a later Pd Vanilla version.
> >>
> >> This bug is probably from Purr Data attempted to support this
> >> deprecated ", f 12;"
> >> syntax plus the fixed behavior that just uses "#X f 12;" on the next
> >> line.
> >>
> >> I'd like to continue supporting both syntaxes, otherwise uses of the
> >> old syntax
> >> will hit the bug and be sad.
> >>
> >> See the note in line above `t_symbol *last_typedmess;` to understand
> >> what's going
> >> on.
> >>
> >> I'll drill down on this later and see what's up.
> >>
> >> And just to be clear-- I only attempted to do damage control around that
> >> looper, I didn't write it. (Yet another reason why we should just be
> >> using arrays,
> >> but that's for another time.)
> >>
> >> -Jonathan
> >>
> >>> I am assuming it is looking for the last element in the gl_list. If so,
> >>> I have no idea how this has worked so far, since I do not see any kind
> >>> of a check whether g->g_next is not NULL... This is also the only place
> >>> in the entire function (canvas_f) that uses t_gobj *g2.
> >>>
> >>> Running uner that assumption, I refactored it as:
> >>>
> >>> g = x->gl_list;
> >>> if (g) // probably unnecessary but hey let's be pedantic
> >>> while (g->g_next)
> >>> g = g->g_next;
> >>>
> >>> Once this is implemented, the segfault now happens on line 2282
> >>> (immediately below) on the first pd_checkobject(&g->g_pd) which also
> >>> segfaults with an invalid read of size 8...
> >>>
> >>>
> >>> On 6/18/2020 4:13 PM, Jonathan Wilkes wrote:
> >>>> On Thu, Jun 18, 2020 at 3:32 PM Ivica Bukvic <ico at vt.edu> wrote:
> >>>>> Valgrind is a bit more descriptive. It does not happen every time
> >>>>> but it does happen nonetheless. Looks like Windows is a lot less
> >>>>> forgiving. I was pasting the content of a simple patch multiple
> >>>>> times (close the window, new window, paste again):
> >>>>>
> >>>>> #N canvas 487 261 450 300 10;
> >>>>> #X floatatom 145 63 5 0 0 0 - - -, f 5;
> >>>>> #X obj 241 123 print;
> >>>>> #X floatatom 126 134 5 0 0 0 - - -, f 5;
> >>>>> #X connect 0 0 1 0;
> >>>>>
> >>>>> ==12982== Invalid read of size 8
> >>>>> ==12982== at 0x436EF3: canvas_f (g_canvas.c:2273)
> >>>> Something's off for me because 2273 isn't inside canvas_f().
> >>>>
> >>>> Can you tell me what's at that line number in whatever is your
> >>>> current branch?
> >>>>
> >>>> -Jonathan
> >>>>
> >>>>> ==12982== by 0x49B977: pd_typedmess (m_class.c:779)
> >>>>> ==12982== by 0x49B7DD: pd_typedmess (m_class.c:883)
> >>>>> ==12982== by 0x4A4D80: binbuf_eval (m_binbuf.c:937)
> >>>>> ==12982== by 0x4AC56B: socketreceiver_read (s_inter.c:615)
> >>>>> ==12982== by 0x4AB554: sys_domicrosleep.constprop.3
> >>>>> (s_inter.c:226)
> >>>>> ==12982== by 0x4AE35A: sys_pollgui (s_inter.c:1155)
> >>>>> ==12982== by 0x4A84B9: m_pollingscheduler (m_sched.c:542)
> >>>>> ==12982== by 0x4A84B9: m_mainloop (m_sched.c:622)
> >>>>> ==12982== by 0x4AAEF9: sys_main (s_main.c:440)
> >>>>> ==12982== by 0x5ED882F: (below main) (libc-start.c:291)
> >>>>> ==12982== Address 0x8 is not stack'd, malloc'd or (recently) free'd
> >>>>> ==12982==
> >>>>> ==12982==
> >>>>> ==12982== Process terminating with default action of signal 11
> >>>>> (SIGSEGV)
> >>>>> ==12982== Access not within mapped region at address 0x8
> >>>>> ==12982== at 0x436EF3: canvas_f (g_canvas.c:2273)
> >>>>> ==12982== by 0x49B977: pd_typedmess (m_class.c:779)
> >>>>> ==12982== by 0x49B7DD: pd_typedmess (m_class.c:883)
> >>>>> ==12982== by 0x4A4D80: binbuf_eval (m_binbuf.c:937)
> >>>>> ==12982== by 0x4AC56B: socketreceiver_read (s_inter.c:615)
> >>>>> ==12982== by 0x4AB554: sys_domicrosleep.constprop.3
> >>>>> (s_inter.c:226)
> >>>>> ==12982== by 0x4AE35A: sys_pollgui (s_inter.c:1155)
> >>>>> ==12982== by 0x4A84B9: m_pollingscheduler (m_sched.c:542)
> >>>>> ==12982== by 0x4A84B9: m_mainloop (m_sched.c:622)
> >>>>> ==12982== by 0x4AAEF9: sys_main (s_main.c:440)
> >>>>> ==12982== by 0x5ED882F: (below main) (libc-start.c:291)
> >>>>> ==12982== If you believe this happened as a result of a stack
> >>>>> ==12982== overflow in your program's main thread (unlikely but
> >>>>> ==12982== possible), you can try to increase the size of the
> >>>>> ==12982== main thread stack using the --main-stacksize= flag.
> >>>>> ==12982== The main thread stack size used in this run was 8388608.
> >>>>> ==12982==
> >>>>> ==12982== HEAP SUMMARY:
> >>>>> ==12982== in use at exit: 355,586 bytes in 3,885 blocks
> >>>>> ==12982== total heap usage: 7,748 allocs, 3,863 frees, 2,870,428
> >>>>> bytes allocated
> >>>>> ==12982==
> >>>>> ==12982== LEAK SUMMARY:
> >>>>> ==12982== definitely lost: 416 bytes in 9 blocks
> >>>>> ==12982== indirectly lost: 85 bytes in 10 blocks
> >>>>> ==12982== possibly lost: 43,438 bytes in 1,323 blocks
> >>>>> ==12982== still reachable: 311,647 bytes in 2,543 blocks
> >>>>> ==12982== suppressed: 0 bytes in 0 blocks
> >>>>> ==12982== Rerun with --leak-check=full to see details of leaked
> >>>>> memory
> >>>>> ==12982==
> >>>>> ==12982== For counts of detected and suppressed errors, rerun
> >>>>> with: -v
> >>>>> ==12982== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0
> >>>>> from 0)
> >>>>>
> >>>>> --
> >>>>> Ivica Ico Bukvic, D.M.A.
> >>>>> Director, Creativity + Innovation
> >>>>> Institute for Creativity, Arts, and Technology
> >>>>>
> >>>>> Virginia Tech
> >>>>> Creative Technologies in Music
> >>>>> School of Performing Arts – 0141
> >>>>> Blacksburg, VA 24061
> >>>>> (540) 231-6139
> >>>>> ico at vt.edu
> >>>>>
> >>>>> ci.icat.vt.edu
> >>>>> www.icat.vt.edu
> >>>>> www.performingarts.vt.edu
> >>>>> l2ork.icat.vt.edu
> >>>>> ico.bukvic.net
> >>> --
> >>> Ivica Ico Bukvic, D.M.A.
> >>> Director, Creativity + Innovation
> >>> Institute for Creativity, Arts, and Technology
> >>>
> >>> Virginia Tech
> >>> Creative Technologies in Music
> >>> School of Performing Arts – 0141
> >>> Blacksburg, VA 24061
> >>> (540) 231-6139
> >>> ico at vt.edu
> >>>
> >>> www.icat.vt.edu
> >>> www.performingarts.vt.edu
> >>> l2ork.icat.vt.edu
> >>> ico.bukvic.net
> >>>
> >> .
> >
> --
> Ivica Ico Bukvic, D.M.A.
> Director, Creativity + Innovation
> Institute for Creativity, Arts, and Technology
>
> Virginia Tech
> Creative Technologies in Music
> School of Performing Arts – 0141
> Blacksburg, VA 24061
> (540) 231-6139
> ico at vt.edu
>
> www.icat.vt.edu
> www.performingarts.vt.edu
> l2ork.icat.vt.edu
> ico.bukvic.net
>