[L2Ork-dev] Segfault using paste from clipboard on Linux
Ivica Ico Bukvic
ico at vt.edu
Thu Jun 18 20:55:19 EDT 2020
I am not even sure if we need to check for argc... That said, the
warning for some reason is not being triggered.
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.
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
More information about the L2Ork-dev
mailing list