* Jörn Nettingsmeier <netti...@stackingdwarves.net> [2012-10-31 17:47]: > On 10/30/2012 10:10 PM, Hans-Christoph Steiner wrote: > >That's a tough one to track down. One thing I'd recommend is to reduce the > >complexity. Specifically, [readanysf~] is a wonderful object, but relies on > >many many libraries and has many layers in it. This bug could have come from > >any one of those libraries in addition to Pd, readanysf, etc. > > > >For the media that you're using, I recommend converting them with 32-bit > >float > >WAVs, the internal format used in Pd. Then you can use [readsf~] or even > >better, load them into tables and play them with [tabplay~].
Not specific to Jörn's crash, but a nice occasion to point out to another Musil technique about soundfile playback: Load the first second of the soundfile into a table. Next load the soundfile to be played back into a [readsf¨] object (providing an offset message to load data starting at second 2). Then use [tabplay~] to play the first second, and use its rightmost outlet bang message to start playback of the remaining audio data via [readsf~]. Rationale here: Instant playback start, desirable with (theatre style/show control) cue-based soundfile players by using ram-based tables, allowing your OS one second of time to open a file from hard disk. Prevents having to load all of your soundfiles into ram. > very good points. i'll definitely follow that advice. > > nonetheless, i'd very much like to track down the issue. yesterday, > i had a very similar crash and was finally able to get a > post-mortem: > > Reading symbols from /usr/local/lib64/pd/bin/pd...done. > [New LWP 19272] > [New LWP 19278] > [New LWP 19276] > [New LWP 19783] > [New LWP 19803] > [New LWP 19785] > [New LWP 19784] > [New LWP 19788] > [New LWP 19787] > [New LWP 19798] > [New LWP 19786] > [New LWP 19799] > [New LWP 19801] > [New LWP 19802] > [New LWP 19800] > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib64/libthread_db.so.1". > Core was generated by `pd DasLamm.pd'. > Program terminated with signal 11, Segmentation fault. > #0 0x000000000046d343 in vu_float () > Missing separate debuginfos, use: zypper install > glibc-debuginfo-2.15-22.6.4.x86_64 > libFLAC8-debuginfo-1.2.1-96.1.2.x86_64 > libasound2-debuginfo-1.0.25-3.5.1.x86_64 > libgcc47-debuginfo-4.7.1_20120723-1.1.1.x86_64 > libjpeg62-debuginfo-62.0.0-15.5.1.x86_64 > libmad0-debuginfo-0.15.1b-3.2.x86_64 > libogg0-debuginfo-1.3.0-4.1.2.x86_64 > libpng12-0-debuginfo-1.2.49-2.1.2.x86_64 > libspeex1-debuginfo-1.1.999_1.2rc1-16.1.2.x86_64 > libstdc++47-debuginfo-4.7.1_20120723-1.1.1.x86_64 > libtheora0-debuginfo-1.1.1-20.1.2.x86_64 > libtiff3-debuginfo-3.9.5-8.10.1.x86_64 > libvorbis0-debuginfo-1.3.3-1.1.2.x86_64 > libvorbisenc2-debuginfo-1.3.3-1.1.2.x86_64 > zlib-debuginfo-1.2.7-2.1.2.x86_64 > (gdb) thread apply all bt > > Thread 15 (Thread 0x7f1542ea9700 (LWP 19800)): > #0 0x00007f15516058f4 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00007f154bdfb02a in ReadMedia::waitA() () from > /usr/local/lib64/pd/extra/readanysf~.pd_linux > #2 0x00007f154bdfc62e in ?? () from > /usr/local/lib64/pd/extra/readanysf~.pd_linux > #3 0x00007f1551601e0e in start_thread () from /lib64/libpthread.so.0 > #4 0x00007f1550a322bd in clone () from /lib64/libc.so.6 > > Thread 14 (Thread 0x7f15416a6700 (LWP 19802)): > #0 0x00007f15516058f4 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00007f154bdfb02a in ReadMedia::waitA() () from > /usr/local/lib64/pd/extra/readanysf~.pd_linux > #2 0x00007f154bdfc62e in ?? () from > /usr/local/lib64/pd/extra/readanysf~.pd_linux > #3 0x00007f1551601e0e in start_thread () from /lib64/libpthread.so.0 > #4 0x00007f1550a322bd in clone () from /lib64/libc.so.6 > > Thread 13 (Thread 0x7f1541ea7700 (LWP 19801)): > #0 0x00007f15516058f4 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00007f154bdfb02a in ReadMedia::waitA() () from > /usr/local/lib64/pd/extra/readanysf~.pd_linux > #2 0x00007f154bdfc62e in ?? () from > /usr/local/lib64/pd/extra/readanysf~.pd_linux > #3 0x00007f1551601e0e in start_thread () from /lib64/libpthread.so.0 > #4 0x00007f1550a322bd in clone () from /lib64/libc.so.6 > > Thread 12 (Thread 0x7f15426a8700 (LWP 19799)): > #0 0x00007f15516058f4 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00007f154bdfb02a in ReadMedia::waitA() () from > /usr/local/lib64/pd/extra/readanysf~.pd_linux > #2 0x00007f154bdfc62e in ?? () from > /usr/local/lib64/pd/extra/readanysf~.pd_linux > #3 0x00007f1551601e0e in start_thread () from /lib64/libpthread.so.0 > #4 0x00007f1550a322bd in clone () from /lib64/libc.so.6 > > Thread 11 (Thread 0x7f1546f15700 (LWP 19786)): > #0 0x00007f15516058f4 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00007f154bdfb10c in ReadMedia::waitDispatch() () from > /usr/local/lib64/pd/extra/readanysf~.pd_linux > #2 0x00007f154bdfbdb8 in ?? () from > /usr/local/lib64/pd/extra/readanysf~.pd_linux > #3 0x00007f1551601e0e in start_thread () from /lib64/libpthread.so.0 > #4 0x00007f1550a322bd in clone () from /lib64/libc.so.6 > > Thread 10 (Thread 0x7f15436aa700 (LWP 19798)): > ---Type <return> to continue, or q <return> to quit---thread apply all bt > #0 0x00007f15516058f4 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00007f154bdfb02a in ReadMedia::waitA() () from > /usr/local/lib64/pd/extra/readanysf~.pd_linux > #2 0x00007f154bdfc62e in ?? () from > /usr/local/lib64/pd/extra/readanysf~.pd_linux > #3 0x00007f1551601e0e in start_thread () from /lib64/libpthread.so.0 > #4 0x00007f1550a322bd in clone () from /lib64/libc.so.6 > > Thread 9 (Thread 0x7f1549369700 (LWP 19787)): > #0 0x00007f15516058f4 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00007f154bdfb10c in ReadMedia::waitDispatch() () from > /usr/local/lib64/pd/extra/readanysf~.pd_linux > #2 0x00007f154bdfbdb8 in ?? () from > /usr/local/lib64/pd/extra/readanysf~.pd_linux > #3 0x00007f1551601e0e in start_thread () from /lib64/libpthread.so.0 > #4 0x00007f1550a322bd in clone () from /lib64/libc.so.6 > > Thread 8 (Thread 0x7f1548924700 (LWP 19788)): > #0 0x00007f15516058f4 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00007f154bdfb10c in ReadMedia::waitDispatch() () from > /usr/local/lib64/pd/extra/readanysf~.pd_linux > #2 0x00007f154bdfbdb8 in ?? () from > /usr/local/lib64/pd/extra/readanysf~.pd_linux > #3 0x00007f1551601e0e in start_thread () from /lib64/libpthread.so.0 > #4 0x00007f1550a322bd in clone () from /lib64/libc.so.6 > > Thread 7 (Thread 0x7f1543eab700 (LWP 19784)): > #0 0x00007f15516058f4 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00007f154bdfb10c in ReadMedia::waitDispatch() () from > /usr/local/lib64/pd/extra/readanysf~.pd_linux > #2 0x00007f154bdfbdb8 in ?? () from > /usr/local/lib64/pd/extra/readanysf~.pd_linux > #3 0x00007f1551601e0e in start_thread () from /lib64/libpthread.so.0 > #4 0x00007f1550a322bd in clone () from /lib64/libc.so.6 > > Thread 6 (Thread 0x7f153bfff700 (LWP 19785)): > #0 0x00007f15516058f4 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00007f154bdfb10c in ReadMedia::waitDispatch() () from > /usr/local/lib64/pd/extra/readanysf~.pd_linux > #2 0x00007f154bdfbdb8 in ?? () from > /usr/local/lib64/pd/extra/readanysf~.pd_linux > #3 0x00007f1551601e0e in start_thread () from /lib64/libpthread.so.0 > #4 0x00007f1550a322bd in clone () from /lib64/libc.so.6 > > Thread 5 (Thread 0x7f1540ea5700 (LWP 19803)): > #0 0x00007f15516058f4 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00007f154bdfb02a in ReadMedia::waitA() () from > /usr/local/lib64/pd/extra/readanysf~.pd_linux > ---Type <return> to continue, or q <return> to quit--- > #2 0x00007f154bdfc62e in ?? () from > /usr/local/lib64/pd/extra/readanysf~.pd_linux > #3 0x00007f1551601e0e in start_thread () from /lib64/libpthread.so.0 > #4 0x00007f1550a322bd in clone () from /lib64/libc.so.6 > > Thread 4 (Thread 0x7f1546714700 (LWP 19783)): > #0 0x00007f15516058f4 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00007f154bdfb10c in ReadMedia::waitDispatch() () from > /usr/local/lib64/pd/extra/readanysf~.pd_linux > #2 0x00007f154bdfbdb8 in ?? () from > /usr/local/lib64/pd/extra/readanysf~.pd_linux > #3 0x00007f1551601e0e in start_thread () from /lib64/libpthread.so.0 > #4 0x00007f1550a322bd in clone () from /lib64/libc.so.6 > > Thread 3 (Thread 0x7f155094d700 (LWP 19276)): > #0 0x00007f15516058f4 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x00007f1550cfdd8b in mb_thread_func () from > /usr/local/lib64/libjack.so.0 > #2 0x00007f1551601e0e in start_thread () from /lib64/libpthread.so.0 > #3 0x00007f1550a322bd in clone () from /lib64/libc.so.6 > > Thread 2 (Thread 0x7f1551c7f700 (LWP 19278)): > #0 0x00007f1550a2a13f in poll () from /lib64/libc.so.6 > #1 0x00007f1550cfc806 in jack_cycle_wait () from > /usr/local/lib64/libjack.so.0 > #2 0x00007f1550cfcb38 in jack_process_thread_work () from > /usr/local/lib64/libjack.so.0 > #3 0x00007f1551601e0e in start_thread () from /lib64/libpthread.so.0 > #4 0x00007f1550a322bd in clone () from /lib64/libc.so.6 > > Thread 1 (Thread 0x7f1551cfc700 (LWP 19272)): > #0 0x000000000046d343 in vu_float () > #1 0x000000000047345f in outlet_float () > #2 0x000000000047345f in outlet_float () > #3 0x000000000047345f in outlet_float () > #4 0x000000000047f412 in m_mainloop () > #5 0x00007f155096f455 in __libc_start_main () from /lib64/libc.so.6 > #6 0x0000000000414df1 in _start () at ../sysdeps/x86_64/elf/start.S:113 > (gdb) > > nothing midi-specific, but obviously a breakage in the vu meter. i > wonder if the odd-looking vus i'm getting (see > http://stackingdwarves.net/download/pd-odd_vu_meter.png) are a hint? Jörn, this won't help you tracking down the crash, but: I once got into the habit of using Thomas Musil's iem_vu, which uses less cpu within Tcl/Tk by employing an alternative rendering technique. I think it is part of one of the iemlibs. May not make a huge difference there, but it might be recognizable with 24 channels of VU meters. And it helps you keeping the Tcl/Tk cpu load down, which could help achieving lower latencies in return. > i think i copied-and-pasted the two vus when i created the 6-channel > player, but i don't see how that could cause a segfault later... Have a look if there are any double copies hidden under these objects, one of the more common and really hard errors to find out about when patching, and a good reason to use the duplicate command instead of copy/paste, as duplicate creates the second object at a slightly different position within the patch. best, Peter _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list