hi *!
two days ago, my pd-based cue player (btw, new release at http://stackingdwarves.net/public_stuff/software/CueFrog/) chashed and burned during a live show. not good.
pd segfaulted while i had one six-channel instance of readanysf running and five more two-channel instances stopped, at the precise moment when i was sending a midi cc to stop the running player and another to start a new one, while i was at the same time moving a midi fader for volume control.
unfortunately, i had core dumps disabled, and as luck would have it, the crash seems impossible to reproduce without an audience of 200 and a director to go ballistic. so unless someone has an audience simulator test scaffold: what are, in your experience, the most likely causes of such sudden segfaults, and are there workarounds or defensive practices which i could implement?
i'm using the current releases of pd-vanilla, vbap and readanysf~.
in case someone feels inclined to look at my programming style and lead me back to the path of righteousness, the actual show patch i was using on top of CueFrog is at http://stackingdwarves.net/download/pd-crash.pd
looking forward to your ideas!
best
jörn
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~].
.hc
On 10/29/2012 03:35 PM, Jörn Nettingsmeier wrote:
hi *!
two days ago, my pd-based cue player (btw, new release at http://stackingdwarves.net/public_stuff/software/CueFrog/) chashed and burned during a live show. not good.
pd segfaulted while i had one six-channel instance of readanysf running and five more two-channel instances stopped, at the precise moment when i was sending a midi cc to stop the running player and another to start a new one, while i was at the same time moving a midi fader for volume control.
unfortunately, i had core dumps disabled, and as luck would have it, the crash seems impossible to reproduce without an audience of 200 and a director to go ballistic. so unless someone has an audience simulator test scaffold: what are, in your experience, the most likely causes of such sudden segfaults, and are there workarounds or defensive practices which i could implement?
i'm using the current releases of pd-vanilla, vbap and readanysf~.
in case someone feels inclined to look at my programming style and lead me back to the path of righteousness, the actual show patch i was using on top of CueFrog is at http://stackingdwarves.net/download/pd-crash.pd
looking forward to your ideas!
best
jörn
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~].
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?
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...
looks like i'm having a hard time to create a proper reproducible test case, but maybe some devs are inspired by this backtrace anyway :)
best,
jörn
- Jörn Nettingsmeier nettings@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
-
Hans-Christoph Steiner -
Jörn Nettingsmeier -
Peter P.