<div dir="ltr">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):<div><br></div><div>#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;</div><div><br></div><div>==12982== Invalid read of size 8<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== 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><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></div></div>