[PD] mysterious segfault while receiving midi commands...

Peter P. p8rpp at aol.com
Wed Oct 31 23:44:56 CET 2012 

* Jörn Nettingsmeier <nettings at 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

More information about the Pd-list mailing list