<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>BTW, developing on Linux after breaking my teeth on MSYS
environment is like a walk in the park. Not to mention the
availability of valgrind (gdb completely missed the error and its
backtrace was rubbish).</p>
<p>Best,</p>
<p>Ico<br>
</p>
<div class="moz-cite-prefix">On 6/18/2020 9:48 PM, Ivica Bukvic
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJrgGbbo0rCXR0pRX_FhQE73W8uyLOSUzWiuk2La9vWJKv8=+A@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">Can you explain what that for loop does as if I am
5 yo? I do not see any checks here where to stop and eventually
you will hit the last object whose g_next is NULL. Does it check
in the middle condition if g2 is not NULL after it was assigned
a new value?<br>
<br>
<div data-smartmail="gmail_signature">Best,<br>
<br>
Ico<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" moz-do-not-send="true">ico@vt.edu</a><br>
<br>
<a href="http://www.icat.vt.edu" moz-do-not-send="true">www.icat.vt.edu</a><br>
<a href="http://www.performingarts.vt.edu"
moz-do-not-send="true">www.performingarts.vt.edu</a><br>
<a href="http://l2ork.icat.vt.edu" moz-do-not-send="true">l2ork.icat.vt.edu</a><br>
<a href="http://ico.bukvic.net" moz-do-not-send="true">ico.bukvic.net</a></div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Jun 18, 2020, 21:44
Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com"
moz-do-not-send="true">jon.w.wilkes@gmail.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Woah-- wait
a sec:<br>
<br>
--> for (g = x->gl_list; g2 = g->g_next; g =
g2)<br>
;<br>
<br>
As weird as it is, that algorithm is sound. And the bug with
", f 12;"<br>
was in the condition<br>
before this one.<br>
<br>
If there is an invalid read by simply walking the glist, then
the<br>
glist has been corrupted.<br>
<br>
So I would check the code for pasting patch snippets to see if
there<br>
is anything that<br>
is corrupting the glist.<br>
<br>
E.g., neglecting to set g->g_next for the final node. Stuff
like that.<br>
<br>
-Jonathan<br>
<br>
On Thu, Jun 18, 2020 at 9:03 PM Jonathan Wilkes <<a
href="mailto:jon.w.wilkes@gmail.com" target="_blank"
rel="noreferrer" moz-do-not-send="true">jon.w.wilkes@gmail.com</a>>
wrote:<br>
><br>
> On Thu, Jun 18, 2020 at 8:55 PM Ivica Ico Bukvic <<a
href="mailto:ico@vt.edu" target="_blank" rel="noreferrer"
moz-do-not-send="true">ico@vt.edu</a>> wrote:<br>
> ><br>
> > I am not even sure if we need to check for argc...
That said, the<br>
> > warning for some reason is not being triggered.<br>
><br>
> Please run purr-data/scripts/regression_test.pd to make
sure this<br>
> isn't breaking anything.<br>
><br>
> ><br>
> > Lastly, please note that creating a patch in
purr-data and saving it<br>
> > still results in the legacy <command>, f
<num>; format for describing<br>
> > the custom width of an object.<br>
><br>
> Ooh, we need to change that.<br>
><br>
> We should open both formats and only save the sane one.<br>
><br>
> -Jonathan<br>
><br>
> ><br>
> > Best,<br>
> ><br>
> > Ico<br>
> ><br>
> > On 6/18/2020 8:53 PM, Ivica Ico Bukvic wrote:<br>
> > > How about simply changing the following inside
canvas_f:<br>
> > ><br>
> > > if (pd_class(last_typedmess_pd) ==
canvas_class &&<br>
> > > (t_canvas *)last_typedmess_pd == x
&&<br>
> > > last_typedmess == gensym("restore"))<br>
> > ><br>
> > > to:<br>
> > ><br>
> > > if (s == gensym("f") && argc >=
1)<br>
> > ><br>
> > > Seems to have fixed the segfault on Linux and
Windows.<br>
> > ><br>
> > > Best,<br>
> > ><br>
> > > Ico<br>
> > ><br>
> > > On 6/18/2020 4:53 PM, Jonathan Wilkes wrote:<br>
> > >> On Thu, Jun 18, 2020 at 4:29 PM Ivica Ico
Bukvic <<a href="mailto:ico@vt.edu" target="_blank"
rel="noreferrer" moz-do-not-send="true">ico@vt.edu</a>>
wrote:<br>
> > >>> 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>
> > >> This is all about that inane ", f $value"
syntax that Miller wrote,<br>
> > >> didn't<br>
> > >> test, and then got changed in a later Pd
Vanilla version.<br>
> > >><br>
> > >> This bug is probably from Purr Data
attempted to support this<br>
> > >> deprecated ", f 12;"<br>
> > >> syntax plus the fixed behavior that just
uses "#X f 12;" on the next<br>
> > >> line.<br>
> > >><br>
> > >> I'd like to continue supporting both
syntaxes, otherwise uses of the<br>
> > >> old syntax<br>
> > >> will hit the bug and be sad.<br>
> > >><br>
> > >> See the note in line above `t_symbol
*last_typedmess;` to understand<br>
> > >> what's going<br>
> > >> on.<br>
> > >><br>
> > >> I'll drill down on this later and see
what's up.<br>
> > >><br>
> > >> And just to be clear-- I only attempted to
do damage control around that<br>
> > >> looper, I didn't write it. (Yet another
reason why we should just be<br>
> > >> using arrays,<br>
> > >> but that's for another time.)<br>
> > >><br>
> > >> -Jonathan<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"
rel="noreferrer" moz-do-not-send="true">ico@vt.edu</a>>
wrote:<br>
> > >>>>> Valgrind is a bit more
descriptive. It does not happen every time<br>
> > >>>>> but it does happen nonetheless.
Looks like Windows is a lot less<br>
> > >>>>> forgiving. I was pasting the
content of a simple patch multiple<br>
> > >>>>> 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<br>
> > >>>> 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<br>
> > >>>>> (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<br>
> > >>>>> (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<br>
> > >>>>> (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<br>
> > >>>>> 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<br>
> > >>>>> memory<br>
> > >>>>> ==12982==<br>
> > >>>>> ==12982== For counts of
detected and suppressed errors, rerun<br>
> > >>>>> with: -v<br>
> > >>>>> ==12982== ERROR SUMMARY: 1
errors from 1 contexts (suppressed: 0<br>
> > >>>>> 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" rel="noreferrer" moz-do-not-send="true">ico@vt.edu</a><br>
> > >>>>><br>
> > >>>>> <a
href="http://ci.icat.vt.edu" rel="noreferrer noreferrer"
target="_blank" moz-do-not-send="true">ci.icat.vt.edu</a><br>
> > >>>>> <a
href="http://www.icat.vt.edu" rel="noreferrer noreferrer"
target="_blank" moz-do-not-send="true">www.icat.vt.edu</a><br>
> > >>>>> <a
href="http://www.performingarts.vt.edu" rel="noreferrer
noreferrer" target="_blank" moz-do-not-send="true">www.performingarts.vt.edu</a><br>
> > >>>>> <a
href="http://l2ork.icat.vt.edu" rel="noreferrer noreferrer"
target="_blank" moz-do-not-send="true">l2ork.icat.vt.edu</a><br>
> > >>>>> <a
href="http://ico.bukvic.net" rel="noreferrer noreferrer"
target="_blank" moz-do-not-send="true">ico.bukvic.net</a><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" rel="noreferrer" moz-do-not-send="true">ico@vt.edu</a><br>
> > >>><br>
> > >>> <a href="http://www.icat.vt.edu"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">www.icat.vt.edu</a><br>
> > >>> <a
href="http://www.performingarts.vt.edu" rel="noreferrer
noreferrer" target="_blank" moz-do-not-send="true">www.performingarts.vt.edu</a><br>
> > >>> <a href="http://l2ork.icat.vt.edu"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">l2ork.icat.vt.edu</a><br>
> > >>> <a href="http://ico.bukvic.net"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">ico.bukvic.net</a><br>
> > >>><br>
> > >> .<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"
rel="noreferrer" moz-do-not-send="true">ico@vt.edu</a><br>
> ><br>
> > <a href="http://www.icat.vt.edu" rel="noreferrer
noreferrer" target="_blank" moz-do-not-send="true">www.icat.vt.edu</a><br>
> > <a href="http://www.performingarts.vt.edu"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">www.performingarts.vt.edu</a><br>
> > <a href="http://l2ork.icat.vt.edu" rel="noreferrer
noreferrer" target="_blank" moz-do-not-send="true">l2ork.icat.vt.edu</a><br>
> > <a href="http://ico.bukvic.net" rel="noreferrer
noreferrer" target="_blank" moz-do-not-send="true">ico.bukvic.net</a><br>
> ><br>
</blockquote>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
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
<a class="moz-txt-link-abbreviated" href="mailto:ico@vt.edu">ico@vt.edu</a>
<a class="moz-txt-link-abbreviated" href="http://www.icat.vt.edu">www.icat.vt.edu</a>
<a class="moz-txt-link-abbreviated" href="http://www.performingarts.vt.edu">www.performingarts.vt.edu</a>
l2ork.icat.vt.edu
ico.bukvic.net</pre>
</body>
</html>