[L2Ork-dev] Segfault using paste from clipboard on Linux

Thu Jun 18 16:55:49 EDT 2020

Here's some more logging, looks like copyfromexternalbuffer does not
instantiate the object in time for the "f" part of the <object>, f
<number>; to reference a valid object

This is initial opening of a patch which works:
gotmess A_SYMBOL: canvas 5 1 487.000000
gotmess A_SYMBOL: obj 3 1 241.000000
gotmess A_SYMBOL: print 0
gotmess A_SYMBOL: floatatom 9 1 145.000000
gotmess A_SYMBOL: f 1 1 5.000000
same canvas g=.x6cf43d0 x=.x6cf3af0
gotmess A_SYMBOL: floatatom 9 1 126.000000
gotmess A_SYMBOL: f 1 1 5.000000
same canvas g=.x6cf43d0 x=.x6cf3af0
same canvas g=.x6cf46f0 x=.x6cf3af0

This is pasting of the same into a blank canvas:
gotmess A_SYMBOL: copyfromexternalbuffer 0
gotmess A_SYMBOL: copyfromexternalbuffer 7 2 -1.000000
gotmess A_SYMBOL: copyfromexternalbuffer 5 2 -1.000000
gotmess A_SYMBOL: copyfromexternalbuffer 11 2 -1.000000
gotmess A_SYMBOL: f 1 1 5.000000
==17608== Invalid read of size 8
==17608==    at 0x4A0F30: pd_checkobject (m_obj.c:665)
==17608==    by 0x4358A1: canvas_f (g_canvas.c:2284)
==17608==    by 0x49ECF7: pd_typedmess (m_class.c:779)
==17608==    by 0x49EB5D: pd_typedmess (m_class.c:883)
==17608==    by 0x4A8F60: binbuf_eval (m_binbuf.c:947)
==17608==    by 0x4B110B: socketreceiver_read (s_inter.c:615)
==17608==    by 0x4B00F4: sys_domicrosleep.constprop.3 (s_inter.c:226)
==17608==    by 0x4B2EFA: sys_pollgui (s_inter.c:1155)
==17608==    by 0x4AD059: m_pollingscheduler (m_sched.c:542)
==17608==    by 0x4AD059: m_mainloop (m_sched.c:622)
==17608==    by 0x4AFA99: sys_main (s_main.c:440)
==17608==    by 0x5ED882F: (below main) (libc-start.c:291)
==17608==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

-- 
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.eduwww.icat.vt.edu
www.performingarts.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net

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)
>                      ;
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200618/1756995c/attachment-0001.html>