Hmm... and (just checking) - you did a make clean and rebuilt everything? The pd_instance structure changed....
I can't get it to fail over here any more... cheers Miller On Wed, Apr 22, 2015 at 05:30:20PM -0400, Dan Wilcox wrote: > Thanks. Unfortunately still a crash, but now at a different place. I also > confirmed that it still runs fine when libpd is compiled with -O3 aka make > DEBUG=true. > > #0 signal_cleanup [inlined] () at > /Users/dano/src/pd/libpd/pure-data/src/d_ugen.c:364 > #1 0x0000000100026680 in ugen_stop () at d_ugen.c:562 > #2 0x000000010002670e in ugen_start () at d_ugen.c:569 > #3 0x000000010003197e in glob_dsp (dummy=0x100102e00, s=0x0, argc=<value > temporarily unavailable, due to optimizations>, argv=0x100102e20) at > g_canvas.c:1086 > #4 0x000000010006d286 in pd_typedmess (x=0x1000a5760, s=0x0, argc=1055232, > argv=0x100102e20) at m_class.c:699 > #5 0x0000000100096fb8 in libpd_message [inlined] () at > /Users/dano/src/pd/libpd/libpd_wrapper/z_libpd.c:236 > #6 0x0000000100096fb8 in libpd_finish_message (recv=<value temporarily > unavailable, due to optimizations>, msg=0x100000f67 "dsp") at z_libpd.c:562 > #7 0x0000000100000b8f in main () > > In detail: > > #0 signal_cleanup [inlined] () at > /Users/dano/src/pd/libpd/pure-data/src/d_ugen.c:364 > 364 pd_this->pd_signals = sig->s_nextused; > (gdb) frame 1 > #1 0x0000000100026680 in ugen_stop () at d_ugen.c:562 > 364 pd_this->pd_signals = sig->s_nextused; > (gdb) frame 2 > #2 0x000000010002670e in ugen_start () at d_ugen.c:569 > 569 ugen_stop(); > (gdb) frame 3 > #3 0x000000010003197e in glob_dsp (dummy=0x100102e00, s=0x0, argc=<value > temporarily unavailable, due to optimizations>, argv=0x100102e20) at > g_canvas.c:1086 > 1086 ugen_start(); > (gdb) frame 4 > #4 0x000000010006d286 in pd_typedmess (x=0x1000a5760, s=0x0, argc=1055232, > argv=0x100102e20) at m_class.c:699 > 699 else (*((t_messgimme)(m->me_fun)))(x, s, argc, argv); > (gdb) frame 5 > #5 0x0000000100096fb8 in libpd_message [inlined] () at > /Users/dano/src/pd/libpd/libpd_wrapper/z_libpd.c:236 > 236 pd_typedmess(dest, gensym(msg), n, v); > (gdb) frame 6 > #6 0x0000000100096fb8 in libpd_finish_message (recv=<value temporarily > unavailable, due to optimizations>, msg=0x100000f67 "dsp") at z_libpd.c:562 > 236 pd_typedmess(dest, gensym(msg), n, v); > (gdb) frame 7 > #7 0x0000000100000b8f in main () > > -------- > Dan Wilcox > @danomatika > danomatika.com <http://danomatika.com/> > robotcowboy.com <http://robotcowboy.com/> > > On Apr 22, 2015, at 5:12 PM, Miller Puckette <[email protected]> wrote: > > > > OK ... I think I fixed it... pull newest from git and try. > > > > thanks > > M > > > > On Wed, Apr 22, 2015 at 12:35:10PM -0700, Miller Puckette wrote: > >> Aha - sometimes things crash on OSX because of "minor" buffer overruns that > >> linux just soldiers past. I'll break out a mac and try again... > >> > >> M > >> > >> On Wed, Apr 22, 2015 at 03:03:09AM -0400, Dan Wilcox wrote: > >>> 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 > _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
