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

Thu Jun 18 20:53:44 EDT 2020

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