Weird. It crashes for me on OSX when libpd is built with -O3 and the program is 
built with or without -O3.

*Note: I just finished reorganizing the libpd samples by language name. If you 
do a pull, the multi instance test is now located in samples/c/pdtest_multi 

Rebuilding and running it again yields:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388
388         for (oc = x->o_connections; oc; oc = oc->oc_next)

#0  outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388
#1  0x000000010006f0b9 in outlet_bang (x=<value temporarily unavailable, due to 
optimizations>) at m_obj.c:363
#2  0x00000001000953f9 in metro_tick (x=0x10021ad90) at x_time.c:162
#3  0x0000000100071010 in sched_tick () at m_sched.c:418
#4  0x0000000100096733 in libpd_process_float (ticks=1, inBuffer=<value 
temporarily unavailable, due to optimizations>, outBuffer=<value temporarily 
unavailable, due to optimizations>) at z_libpd.c:185
#5  0x0000000100000d67 in main ()

some frame detail:

(gdb) frame 0
#0  outlet_float (x=0x3f7ffc2a3f7ffc38, f=0) at m_obj.c:388
388         for (oc = x->o_connections; oc; oc = oc->oc_next)
(gdb) frame 1
#1  0x000000010006f0b9 in outlet_bang (x=<value temporarily unavailable, due to 
optimizations>) at m_obj.c:363
363             pd_bang(oc->oc_to);
(gdb) frame 2
#2  0x00000001000953f9 in metro_tick (x=0x10021ad90) at x_time.c:162
162         outlet_bang(x->x_obj.ob_outlet);
(gdb) frame 3
#3  0x0000000100071010 in sched_tick () at m_sched.c:418
418             (*c->c_fn)(c->c_owner);
(gdb) frame 4
#4  0x0000000100096733 in libpd_process_float (ticks=1, inBuffer=<value 
temporarily unavailable, due to optimizations>, outBuffer=<value temporarily 
unavailable, due to optimizations>) at z_libpd.c:185
185       PROCESS(,)
(gdb) frame 5
#5  0x0000000100000d67 in main ()

--------
Dan Wilcox
@danomatika
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
> On Apr 22, 2015, at 12:15 AM, Miller Puckette <[email protected]> wrote:
> 
> I think it was optimized since I had already made libpd, not from the
> sampes/.../multi directory.  But anyhow I re-did it as you suggest with
> the same result....  can't make it fail...
> 
> cheers
> M
> 
> On Wed, Apr 22, 2015 at 12:03:28AM -0400, Dan Wilcox wrote:
>> You ran it without the optimizations since I added the debug option. Remove 
>> DEBUG=true from line 33 in the Makefile: 
>> https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#L33
>>  
>> <https://github.com/libpd/libpd/blob/master/samples/c_samples/multi/Makefile#L33>
>>  and do a full clean before rebuilding:
>> 
>> cd ../../../ && make clobber && cd - && make
>> --------
>> Dan Wilcox
>> @danomatika
>> danomatika.com <http://danomatika.com/>
>> robotcowboy.com <http://robotcowboy.com/>
>>> On Apr 21, 2015, at 11:57 PM, Miller Puckette <[email protected]> wrote:
>>> 
>>> Hi Dan et al -
>>> 
>>> I gave this a try:
>>> 
>>> git clone https://github.com/libpd/libpd.git
>>> 
>>> [copies pd sources into libpd/pure-data]
>>> 
>>> cd libpd
>>> make
>>> 
>>> cd samples/c_samples/multi/
>>> make
>>> ./multi_pdtest multi_test.pd `pwd`
>>> 
>>> and got output:
>>> 
>>> print: 0
>>> 1003-frequency: bang
>>> print: 0
>>> 1004-frequency: bang
>>> 1003-frequency: 1
>>> 1004-frequency: 2
>>> 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 
>>> 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 
>>> print: 1
>>> 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 
>>> print: 1
>>> 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 
>>> print: 2
>>> print: 2
>>> 
>>> This on Fedora 21, 64 bits, Intel hardware.  
>>> 
>>> I guess something subtle is happening, maybe in Pd and unrelated to libpd?
>>> 
>>> cheers
>>> Miller
>>> 
>>> On Tue, Apr 21, 2015 at 06:00:15PM -0400, Dan Wilcox wrote:
>>>> Howdy Miller,
>>>> 
>>>> Following up from the dev list last year, I added your multi instance test 
>>>> to the c samples included with libpd: 
>>>> https://github.com/libpd/libpd/tree/master/samples/c_samples/multi 
>>>> <https://github.com/libpd/libpd/tree/master/samples/c_samples/multi>
>>>> 
>>>> The one thing I want to double check is the changes to z_libpd.c you 
>>>> mentioned in 
>>>> http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html: 
>>>> <http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html:>
>>>> 
>>>>> Here's how I modified libpd_wrapper/z_libpd.c:
>>>>> 
>>>>> 55d54
>>>>> <   sys_time = 0;
>>>>> 110c109
>>>>> <   sched_tick(sys_time + sys_time_per_dsp_tick);
>>>>> ---
>>>>>> 
>>>>>  sched_tick();
>>>>> 
>>>>> 130c129
>>>>> <     sched_tick(sys_time + sys_time_per_dsp_tick); \
>>>>> ---
>>>>>> 
>>>>>    sched_tick(); \
>>>> 
>>>> 
>>>> Currently, that line is 
>>>> https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171 
>>>> <https://github.com/libpd/libpd/blob/master/libpd_wrapper/z_libpd.c#L171> 
>>>> and I’m getting a segfault if I replace it with sched_tick(); AND set gcc 
>>>> optimization to -O3
>>>> 
>>>> Here’s a gdb backtrace:
>>>> 
>>>> #0  0x0000000100091f2f in outlet_float (x=0x3f7ffc2a3f7ffc38, 
>>>> f=0.999937057) at m_obj.c:388
>>>> #1  0x00000001000ac572 in pdfloat_bang (x=0x10021ac20) at x_connective.c:89
>>>> #2  0x0000000100093d58 in pd_bang (x=0x10021ac20) at m_pd.c:267
>>>> #3  0x0000000100091ddd in outlet_bang (x=0x10021ae20) at m_obj.c:363
>>>> #4  0x00000001000c45e4 in metro_tick (x=0x10021ada0) at x_time.c:162
>>>> #5  0x0000000100095021 in sched_tick () at m_sched.c:418
>>>> #6  0x00000001000c5d4d in libpd_process_float (ticks=1, 
>>>> inBuffer=0x7fff5fbffa50, outBuffer=0x7fff5fbff750) at z_libpd.c:173
>>>> #7  0x0000000100000d18 in main ()
>>>> 
>>>> If I don’t optimize, it works fine:
>>>> 
>>>> print: 0
>>>> 1003-frequency: bang
>>>> print: 0
>>>> 1004-frequency: bang
>>>> 1003-frequency: 1
>>>> 1004-frequency: 2
>>>> 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 
>>>> 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 
>>>> print: 1
>>>> 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 
>>>> print: 1
>>>> 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 
>>>> print: 2
>>>> print: 2
>>>> 
>>>> --------
>>>> Dan Wilcox
>>>> @danomatika
>>>> danomatika.com <http://danomatika.com/>
>>>> robotcowboy.com <http://robotcowboy.com/>
>>>>> On Apr 21, 2015, at 10:56 AM, Kjetil Matheussen 
>>>>> <[email protected]> wrote:
>>>>> 
>>>>> But for libpd, are you sure you need to add anything? Can't just the user
>>>>> call the pdinstance_new and pd_setinstance functions directly?
>>>>> 
>>>>> http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html 
>>>>> <http://lists.puredata.info/pipermail/pd-dev/2014-05/019832.html>
>>>>> 
>>>>> 
>>>>> (BTW. When I wrote about libpds, I hadn't forgotten about the support for 
>>>>> pd instances,
>>>>> but since I didn't have all details in my head then, I didn't mention it. 
>>>>> I should have though.)
>>>>> 
>>>>> 
>>>>> On Tue, Apr 21, 2015 at 4:42 PM, Dan Wilcox <[email protected] 
>>>>> <mailto:[email protected]>> wrote:
>>>>> This should be possible with the current version of libpd which includes 
>>>>> Miller’s multiple instance updates, see 
>>>>> http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html 
>>>>> <http://lists.puredata.info/pipermail/pd-dev/2014-05/019839.html>
>>>>> 
>>>>> I just haven’t gotten around to adding libpd-specific wrapper functions 
>>>>> for this yet, but Miller provides code in that dev list exchange.
>>>>> 
>>>>> --------
>>>>> Dan Wilcox
>>>>> @danomatika
>>>>> danomatika.com <http://danomatika.com/>
>>>>> robotcowboy.com <http://robotcowboy.com/>
>>>>>> On Apr 21, 2015, at 6:00 AM, [email protected] 
>>>>>> <mailto:[email protected]> wrote:
>>>>>> 
>>>>>> From: Oliver Greschke <[email protected] <mailto:[email protected]>>
>>>>>> Subject: [PD-dev] Can somebody help to create a desktop / VST / AU 
>>>>>> version of a PD / libPD / app ?
>>>>>> Date: April 21, 2015 at 3:15:44 AM EDT
>>>>>> To: [email protected] <mailto:[email protected]>
>>>>>> 
>>>>>> 
>>>>>> Hi,
>>>>>> I am the creator of the Elastic Drums iOS app (with great PD help from 
>>>>>> Matt Davey).
>>>>>> It’s made with PureData, libPD and Objective-C.
>>>>>> I got asked a couple of times now, if there will be ever a standalone 
>>>>>> desktop version or even better Plugin (VST, AU) version of the app.
>>>>>> 
>>>>>> As far as I know, there are not ready to use workarounds to do so. Which 
>>>>>> is sad, because I can imagine a lot of fantastic plugins emerging from PD
>>>>>> 
>>>>>> Has somebody here some experience with doing such ports?
>>>>>> Then please contact me.
>>>>>> 
>>>>>> Cheers,
>>>>>> Oliver
>>>>>> 
>>>>>> [email protected] <mailto:[email protected]>
>>>>> 
>>>>> _______________________________________________
>>>>> Pd-dev mailing list
>>>>> [email protected] <mailto:[email protected]>
>>>>> http://lists.puredata.info/listinfo/pd-dev 
>>>>> <http://lists.puredata.info/listinfo/pd-dev>
>>>>> 
>>>>> 
>>>> 
>>> 
>>>> _______________________________________________
>>>> Pd-dev mailing list
>>>> [email protected]
>>>> http://lists.puredata.info/listinfo/pd-dev
>>> 
>> 

_______________________________________________
Pd-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev

Reply via email to