<div dir="ltr">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<div><br></div><div>This is initial opening of a patch which works:</div><div>gotmess A_SYMBOL: canvas 5 1 487.000000<br>gotmess A_SYMBOL: obj 3 1 241.000000<br>gotmess A_SYMBOL: print 0 <br>gotmess A_SYMBOL: floatatom 9 1 145.000000<br>gotmess A_SYMBOL: f 1 1 5.000000<br>same canvas g=.x6cf43d0 x=.x6cf3af0<br>gotmess A_SYMBOL: floatatom 9 1 126.000000<br>gotmess A_SYMBOL: f 1 1 5.000000<br>same canvas g=.x6cf43d0 x=.x6cf3af0<br>same canvas g=.x6cf46f0 x=.x6cf3af0<br><br><br>This is pasting of the same into a blank canvas:<br>gotmess A_SYMBOL: copyfromexternalbuffer 0 <br>gotmess A_SYMBOL: copyfromexternalbuffer 7 2 -1.000000<br>gotmess A_SYMBOL: copyfromexternalbuffer 5 2 -1.000000<br>gotmess A_SYMBOL: copyfromexternalbuffer 11 2 -1.000000<br>gotmess A_SYMBOL: f 1 1 5.000000<br>==17608== Invalid read of size 8<br>==17608==    at 0x4A0F30: pd_checkobject (m_obj.c:665)<br>==17608==    by 0x4358A1: canvas_f (g_canvas.c:2284)<br>==17608==    by 0x49ECF7: pd_typedmess (m_class.c:779)<br>==17608==    by 0x49EB5D: pd_typedmess (m_class.c:883)<br>==17608==    by 0x4A8F60: binbuf_eval (m_binbuf.c:947)<br>==17608==    by 0x4B110B: socketreceiver_read (s_inter.c:615)<br>==17608==    by 0x4B00F4: sys_domicrosleep.constprop.3 (s_inter.c:226)<br>==17608==    by 0x4B2EFA: sys_pollgui (s_inter.c:1155)<br>==17608==    by 0x4AD059: m_pollingscheduler (m_sched.c:542)<br>==17608==    by 0x4AD059: m_mainloop (m_sched.c:622)<br>==17608==    by 0x4AFA99: sys_main (s_main.c:440)<br>==17608==    by 0x5ED882F: (below main) (libc-start.c:291)<br>==17608==  Address 0x0 is not stack'd, malloc'd or (recently) free'd<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><pre cols="72"><pre cols="72">-- <br>Ivica Ico Bukvic, D.M.A.<br>Director, Creativity + Innovation<br>Institute for Creativity, Arts, and Technology<br><br>Virginia Tech<br>Creative Technologies in Music<br>School of Performing Arts – 0141<br>Blacksburg, VA 24061<br>(540) 231-6139<br><a href="mailto:ico@vt.edu" target="_blank">ico@vt.edu</a><br><br><a href="http://ci.icat.vt.edu" target="_blank">ci.icat.vt.edu</a>
<a href="http://www.icat.vt.edu" target="_blank">www.icat.vt.edu</a><br><a href="http://www.performingarts.vt.edu" target="_blank">www.performingarts.vt.edu</a><br><a href="http://l2ork.icat.vt.edu" target="_blank">l2ork.icat.vt.edu</a><br><a href="http://ico.bukvic.net" target="_blank">ico.bukvic.net</a></pre></pre></div></div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 18, 2020 at 4:29 PM Ivica Ico Bukvic <<a href="mailto:ico@vt.edu">ico@vt.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It's by far the most SNAFU'd implementation of a for loop I've ever <br>
seen. So much so, I am not even sure what it exactly does:<br>
<br>
    -->     for (g = x->gl_list; g2 = g->g_next; g = g2)<br>
                     ;<br>
<br>
I am assuming it is looking for the last element in the gl_list. If so, <br>
I have no idea how this has worked so far, since I do not see any kind <br>
of a check whether g->g_next is not NULL... This is also the only place <br>
in the entire function (canvas_f) that uses t_gobj *g2.<br>
<br>
Running uner that assumption, I refactored it as:<br>
<br>
g = x->gl_list;<br>
if (g) // probably unnecessary but hey let's be pedantic<br>
     while (g->g_next)<br>
         g = g->g_next;<br>
<br>
Once this is implemented, the segfault now happens on line 2282 <br>
(immediately below) on the first pd_checkobject(&g->g_pd) which also <br>
segfaults with an invalid read of size 8...<br>
<br>
<br>
On 6/18/2020 4:13 PM, Jonathan Wilkes wrote:<br>
> On Thu, Jun 18, 2020 at 3:32 PM Ivica Bukvic <<a href="mailto:ico@vt.edu" target="_blank">ico@vt.edu</a>> wrote:<br>
>> 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):<br>
>><br>
>> #N canvas 487 261 450 300 10;<br>
>> #X floatatom 145 63 5 0 0 0 - - -, f 5;<br>
>> #X obj 241 123 print;<br>
>> #X floatatom 126 134 5 0 0 0 - - -, f 5;<br>
>> #X connect 0 0 1 0;<br>
>><br>
>> ==12982== Invalid read of size 8<br>
>> ==12982==    at 0x436EF3: canvas_f (g_canvas.c:2273)<br>
> Something's off for me because 2273 isn't inside canvas_f().<br>
><br>
> Can you tell me what's at that line number in whatever is your current branch?<br>
><br>
> -Jonathan<br>
><br>
>> ==12982==    by 0x49B977: pd_typedmess (m_class.c:779)<br>
>> ==12982==    by 0x49B7DD: pd_typedmess (m_class.c:883)<br>
>> ==12982==    by 0x4A4D80: binbuf_eval (m_binbuf.c:937)<br>
>> ==12982==    by 0x4AC56B: socketreceiver_read (s_inter.c:615)<br>
>> ==12982==    by 0x4AB554: sys_domicrosleep.constprop.3 (s_inter.c:226)<br>
>> ==12982==    by 0x4AE35A: sys_pollgui (s_inter.c:1155)<br>
>> ==12982==    by 0x4A84B9: m_pollingscheduler (m_sched.c:542)<br>
>> ==12982==    by 0x4A84B9: m_mainloop (m_sched.c:622)<br>
>> ==12982==    by 0x4AAEF9: sys_main (s_main.c:440)<br>
>> ==12982==    by 0x5ED882F: (below main) (libc-start.c:291)<br>
>> ==12982==  Address 0x8 is not stack'd, malloc'd or (recently) free'd<br>
>> ==12982==<br>
>> ==12982==<br>
>> ==12982== Process terminating with default action of signal 11 (SIGSEGV)<br>
>> ==12982==  Access not within mapped region at address 0x8<br>
>> ==12982==    at 0x436EF3: canvas_f (g_canvas.c:2273)<br>
>> ==12982==    by 0x49B977: pd_typedmess (m_class.c:779)<br>
>> ==12982==    by 0x49B7DD: pd_typedmess (m_class.c:883)<br>
>> ==12982==    by 0x4A4D80: binbuf_eval (m_binbuf.c:937)<br>
>> ==12982==    by 0x4AC56B: socketreceiver_read (s_inter.c:615)<br>
>> ==12982==    by 0x4AB554: sys_domicrosleep.constprop.3 (s_inter.c:226)<br>
>> ==12982==    by 0x4AE35A: sys_pollgui (s_inter.c:1155)<br>
>> ==12982==    by 0x4A84B9: m_pollingscheduler (m_sched.c:542)<br>
>> ==12982==    by 0x4A84B9: m_mainloop (m_sched.c:622)<br>
>> ==12982==    by 0x4AAEF9: sys_main (s_main.c:440)<br>
>> ==12982==    by 0x5ED882F: (below main) (libc-start.c:291)<br>
>> ==12982==  If you believe this happened as a result of a stack<br>
>> ==12982==  overflow in your program's main thread (unlikely but<br>
>> ==12982==  possible), you can try to increase the size of the<br>
>> ==12982==  main thread stack using the --main-stacksize= flag.<br>
>> ==12982==  The main thread stack size used in this run was 8388608.<br>
>> ==12982==<br>
>> ==12982== HEAP SUMMARY:<br>
>> ==12982==     in use at exit: 355,586 bytes in 3,885 blocks<br>
>> ==12982==   total heap usage: 7,748 allocs, 3,863 frees, 2,870,428 bytes allocated<br>
>> ==12982==<br>
>> ==12982== LEAK SUMMARY:<br>
>> ==12982==    definitely lost: 416 bytes in 9 blocks<br>
>> ==12982==    indirectly lost: 85 bytes in 10 blocks<br>
>> ==12982==      possibly lost: 43,438 bytes in 1,323 blocks<br>
>> ==12982==    still reachable: 311,647 bytes in 2,543 blocks<br>
>> ==12982==         suppressed: 0 bytes in 0 blocks<br>
>> ==12982== Rerun with --leak-check=full to see details of leaked memory<br>
>> ==12982==<br>
>> ==12982== For counts of detected and suppressed errors, rerun with: -v<br>
>> ==12982== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)<br>
>><br>
>> --<br>
>> Ivica Ico Bukvic, D.M.A.<br>
>> Director, Creativity + Innovation<br>
>> Institute for Creativity, Arts, and Technology<br>
>><br>
>> Virginia Tech<br>
>> Creative Technologies in Music<br>
>> School of Performing Arts – 0141<br>
>> Blacksburg, VA 24061<br>
>> (540) 231-6139<br>
>> <a href="mailto:ico@vt.edu" target="_blank">ico@vt.edu</a><br>
>><br>
>> <a href="http://ci.icat.vt.edu" rel="noreferrer" target="_blank">ci.icat.vt.edu</a><br>
>> <a href="http://www.icat.vt.edu" rel="noreferrer" target="_blank">www.icat.vt.edu</a><br>
>> <a href="http://www.performingarts.vt.edu" rel="noreferrer" target="_blank">www.performingarts.vt.edu</a><br>
>> <a href="http://l2ork.icat.vt.edu" rel="noreferrer" target="_blank">l2ork.icat.vt.edu</a><br>
>> <a href="http://ico.bukvic.net" rel="noreferrer" target="_blank">ico.bukvic.net</a><br>
<br>
-- <br>
Ivica Ico Bukvic, D.M.A.<br>
Director, Creativity + Innovation<br>
Institute for Creativity, Arts, and Technology<br>
<br>
Virginia Tech<br>
Creative Technologies in Music<br>
School of Performing Arts – 0141<br>
Blacksburg, VA 24061<br>
(540) 231-6139<br>
<a href="mailto:ico@vt.edu" target="_blank">ico@vt.edu</a><br>
<br>
<a href="http://www.icat.vt.edu" rel="noreferrer" target="_blank">www.icat.vt.edu</a><br>
<a href="http://www.performingarts.vt.edu" rel="noreferrer" target="_blank">www.performingarts.vt.edu</a><br>
<a href="http://l2ork.icat.vt.edu" rel="noreferrer" target="_blank">l2ork.icat.vt.edu</a><br>
<a href="http://ico.bukvic.net" rel="noreferrer" target="_blank">ico.bukvic.net</a><br>
<br>
</blockquote></div>