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

[Ivica Bukvic]

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)
==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.eduwww.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/3d14e8a4/attachment.html>