[L2Ork-dev] preset_hub bug
Ivica Ico Bukvic
ico at vt.edu
Fri Dec 7 06:05:01 UTC 2012
Jonathan,
It appears I finally found it. It was one of those sneaky ones. The
combination of actions that triggered problems are now gone. I haven't
extensively tested for segfault you got from using reset but my
suspicion is this should solve that as well since the bug was
responsible for messing-up single-linked pointer lists. I am copying
this email to the l2ork-dev list for the record.
Please try the latest git and report. As a shortcut, just go into the
pd/src folder, then:
./configure --enable-alsa --enable-jack --prefix=/usr/local (if you have
script-based installation, or --prefix=/usr for deb installs)
make
sudo cp ../bin/pd-l2ork /usr/local/bin (or for deb installs /usr/bin/)
That way you don't have to rebuild the entire thing...
NB: I also fixed a couple stray things in the git as well, including
another potential reference of unallocated memory (identified by
valgrind which I wholeheartedly recommend over gdb) and two cosmetic
inconsistencies:
1) images not being recognized by the scrolling algorithm, mainly due to
crappy implementation of tcl/tk canvas's image support
2) iemgui number when drawn without the frame was not properly detected
by the scrolling algorithm
Best wishes,
Ico
On 12/06/2012 10:45 PM, Ivica Ico Bukvic wrote:
> I've seen those errors before. They are extremely convoluted as they
> provide no useful info (they crash deep inside the core lib unrelated
> to pd-l2ork) and usually suggest something is not being
> allocated/reallocated properly... I shall investigate...
>
> On 12/06/2012 08:58 PM, Jonathan Wilkes wrote:
>> No. In fact, when I try it for awhile, send a "reset" message to the
>> preset_hub,
>> and move the sliders I get a segfault:
>>
>> (gdb) backtrace
>> #0 malloc_consolidate (av=0x7ffff6fe2e60) at malloc.c:5155
>> #1 0x00007ffff6cd74a8 in _int_free (av=0x7ffff6fe2e60, p=0xc65e50)
>> at malloc.c:5034
>> #2 0x00007ffff6cdb473 in _int_realloc (av=0x7ffff6fe2e60,
>> oldp=0xc65de0, oldsize=272, nb=112) at malloc.c:5369
>> #3 0x00007ffff6cdba60 in *__GI___libc_realloc (oldmem=0xc65df0,
>> bytes=96) at malloc.c:3821
>> #4 0x000000000048ca54 in resizebytes (old=old at entry=0xc65df0,
>> oldsize=<optimized out>, newsize=<optimized out>) at m_memory.c:58
>> #5 0x000000000048cdfa in binbuf_text (x=0xb343c0,
>> text=text at entry=0x7fffffffd0a0 ".xc2b430 motion 105.0 62.0 0
>> ;;;0x302+542+141 ;",
>> size=size at entry=30) at m_binbuf.c:231
>> #6 0x0000000000498b3e in socketreceiver_doread (x=x at entry=0xb34400)
>> at s_inter.c:449
>> #7 0x000000000049ac98 in socketreceiver_read (x=0xb34400, fd=8) at
>> s_inter.c:555
>> #8 0x0000000000498efa in sys_domicrosleep (microsec=<optimized out>,
>> pollem=1) at s_inter.c:198
>> #9 0x0000000000498f95 in sys_microsleep (microsec=<optimized out>)
>> at s_inter.c:220
>> #10 0x0000000000495cad in m_pollingscheduler () at m_sched.c:510
>> #11 m_mainloop () at m_sched.c:560
>> #12 0x00000000004989a4 in sys_main (argc=<optimized out>,
>> argv=<optimized out>) at s_main.c:306
>> #13 0x00007ffff6c7eead in __libc_start_main (main=<optimized out>,
>> argc=<optimized out>, ubp_av=<optimized out>, init=<optimized out>,
>> fini=<optimized out>, rtld_fini=<optimized out>,
>> stack_end=0x7fffffffe428) at libc-start.c:228
>> #14 0x0000000000415481 in _start ()
>>
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: Ivica Ico Bukvic <ico at vt.edu>
>>> To: Jonathan Wilkes <jancsika at yahoo.com>
>>> Cc:
>>> Sent: Thursday, December 6, 2012 8:35 PM
>>> Subject: Re: preset demo
>>>
>>> Weird, when I enable preset debugging, it works like it should, but
>>> when
>>> it is disabled, it freaks out??? Try changing at the top of
>>> x_preset.c line:
>>>
>>> #define PH_DEBUG 0
>>>
>>> to
>>>
>>> #define PH_DEBUG 1
>>>
>>> and recompile for debug info and see if it still misbehaves...
>>>
>>> Ico
>>>
>>> On 12/06/2012 08:23 PM, Jonathan Wilkes wrote:
>>>> Yes, just tested it with git version about an hour ago and it's the
>>> same.
>>>> -Jonathan
>>>>
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: Ivica Ico Bukvic <ico at vt.edu>
>>>>> To: Jonathan Wilkes <jancsika at yahoo.com>
>>>>> Cc:
>>>>> Sent: Thursday, December 6, 2012 6:13 PM
>>>>> Subject: Re: preset demo
>>>>>
>>>>> Is this with git updates?
>>>>>
>>>>> On 12/06/2012 05:37 PM, Jonathan Wilkes wrote:
>>>>>> Here's a simpler test attached:
>>>>>> 1) Move the hslider to the middle
>>>>>> 2) Click [store 1(
>>>>>> 3) Move the vlsider all the way up.
>>>>>> 4) Click [store 2(
>>>>>> 5) Click [recall 2(
>>>>>>
>>>>>> Bug: hslider jumps all the way to the right.
>>>>>>
>>>>>> Pd-l2ork version 20121206
>>>>>>
>>>>>> -Jonathan
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: Ivica Ico Bukvic <ico at vt.edu>
>>>>>>> To: Jonathan Wilkes <jancsika at yahoo.com>
>>>>>>> Cc:
>>>>>>> Sent: Thursday, December 6, 2012 12:19 AM
>>>>>>> Subject: Re: preset demo
>>>>>>>
>>>>>>> Couple of questions. Your patch already comes with some
>>> presets. Were
>>>>> these made
>>>>>>> on an older version of pd-l2ork? If so, it could've been
>>> a
>>>>> regression that
>>>>>>> caused entire patch to be unstable. When I reset the hub and
>>> zero
>>>>> everything out
>>>>>>> by storing them once throughout (I also move each number to
>>> give some
>>>>> value to
>>>>>>> store) and then recalling them, everything works as expected
>>> and I get
>>>>> no
>>>>>>> crashes (NB: I did make two changes inside the x_preset.c
>>> however, just
>>>>> to
>>>>>>> explicitly declare starting variables as null, although I am
>>> not sure
>>>>> if this is
>>>>>>> absolutely necessary or that it makes any difference--you can
>>> get the
>>>>> new source
>>>>>>> from the git to try out). However, your patch in its original
>>> form
>>>>> crashes
>>>>>>> pd-l2ork over here left and right which suggests corrupt data
>>> point
>>>>> somewhere
>>>>>>> (both before and after patching the x_preset.c). Did you
>>> perhaps edit
>>>>> the ps.pd
>>>>>>> file by hand?
>>>>>>>
>>>>>>> The attached file works perfectly fine once I purged the old
>>> presets...
>>>>> You can
>>>>>>> try it with ps-test.pd (same abstraction as yours so not
>>> included),
>>>>> click on
>>>>>>> recall to see what was recorded (in this case only the number
>>> inside
>>>>> the
>>>>>>> abstraction), then click on reset to clear entire hub data,
>>> then store
>>>>> and
>>>>>>> record something and it should just work... If it doesn't
>>> then
>>>>> maybe changes
>>>>>>> I made did make a bit of difference...
>>>>>>>
>>>>>>> Regarding the any object, I am not supporting those (yet)
>>> since they
>>>>> are not
>>>>>>> vanilla objects. Quite frankly, looking at [any]
>>> documentation, I am
>>>>> still
>>>>>>> trying to wrap my head around it... Do you have updated
>>> documentation
>>>>> for it?
>>>>>>> On 12/05/2012 10:33 PM, Jonathan Wilkes wrote:
>>>>>>>> Yes, that's why I put the delay up to 5 seconds.
>>> That's
>>>>> the
>>>>>>> behavior I get too.
>>>>>>>> Also, it seems to have trouble with anythings (in which
>>> case
>>>>> %preset% would
>>>>>>>> obviously be problematic, too). E.g.: [preset_node
>>> foo]---[any]
>>>>>>> doesn't work.
>>>>>>>> So I guess it's float/symbol/list handling
>>>>>>>>
>>>>>>>> -Jonathan
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: Ivica Ico Bukvic <ico at vt.edu>
>>>>>>>>> To: 'Jonathan Wilkes'
>>> <jancsika at yahoo.com>
>>>>>>>>> Cc:
>>>>>>>>> Sent: Wednesday, December 5, 2012 10:00 PM
>>>>>>>>> Subject: RE: preset demo
>>>>>>>>>
>>>>>>>>> Actually, check that. When moving abstraction, for
>>> some
>>>>> reason vertical
>>>>>>>>> slider also gets some of the data... Hmmm...
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Jonathan Wilkes
>>> [mailto:jancsika at yahoo.com]
>>>>>>>>>> Sent: Wednesday, December 05, 2012 9:36 PM
>>>>>>>>>> To: Ivica Ico Bukvic
>>>>>>>>>> Subject: preset demo
>>>>>>>>>>
>>>>>>>>>> Hi Ivica,
>>>>>>>>>>
>>>>>>>>>> Click "store", then click the bang
>>> at the
>>>>> top. When
>>>>>>> the first
>>>>>>>>> [bng]
>>>>>>>>> flashes
>>>>>>>>>> move the sliders and numberbox a little bit.
>>> Then
>>>>> click
>>>>>>> "recall"
>>>>>>>>> and play
>>>>>>>>> it
>>>>>>>>>> back.
>>>>>>>>>>
>>>>>>>>>> It looks different when I play it back. Do I
>>> have a
>>>>> problem in
>>>>>>> my patch?
>>>>>>>>>> -Jonathan
>>>>>>> -- Ivica Ico Bukvic, D.M.A
>>>>>>> Composition, Music Technology
>>>>>>> Director, DISIS Interactive Sound & Intermedia Studio
>>>>>>> Director, L2Ork Linux Laptop Orchestra
>>>>>>> Head, ICAT IMPACT Studio
>>>>>>> Virginia Tech
>>>>>>> Department of Music
>>>>>>> Blacksburg, VA 24061-0240
>>>>>>> (540) 231-6139
>>>>>>> (540) 231-5034 (fax)
>>>>>>> disis.music.vt.edu
>>>>>>> l2ork.music.vt.edu
>>>>>>> ico.bukvic.net
>>>>> --
>>>>> Ivica Ico Bukvic, D.M.A
>>>>> Composition, Music Technology
>>>>> Director, DISIS Interactive Sound & Intermedia Studio
>>>>> Director, L2Ork Linux Laptop Orchestra
>>>>> Head, ICAT IMPACT Studio
>>>>> Virginia Tech
>>>>> Department of Music
>>>>> Blacksburg, VA 24061-0240
>>>>> (540) 231-6139
>>>>> (540) 231-5034 (fax)
>>>>> disis.music.vt.edu
>>>>> l2ork.music.vt.edu
>>>>> ico.bukvic.net
>>>>>
>>>
>>> --
>>> Ivica Ico Bukvic, D.M.A
>>> Composition, Music Technology
>>> Director, DISIS Interactive Sound & Intermedia Studio
>>> Director, L2Ork Linux Laptop Orchestra
>>> Head, ICAT IMPACT Studio
>>> Virginia Tech
>>> Department of Music
>>> Blacksburg, VA 24061-0240
>>> (540) 231-6139
>>> (540) 231-5034 (fax)
>>> disis.music.vt.edu
>>> l2ork.music.vt.edu
>>> ico.bukvic.net
>>>
>
>
--
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Head, ICAT IMPACT Studio
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net
More information about the L2Ork-dev
mailing list