View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000919 | ardour | bugs | public | 2005-03-04 22:27 | 2008-11-20 23:42 |
| Reporter | nklepeis | Assigned To | paul | ||
| Priority | normal | Severity | crash | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | ||
| Summary | 0000919: Freeze-ups during and just after recording | ||||
| Description | Using ardour-0.9beta27, I experience two kinds of GUI freezes: (1) using a brand new session, the ardour GUI sometimes freezes during the first few minutes of recording and, (2) when I can record for longer than 2-3 minutes, sometimes when I quit ardour the GUI freezes. Sometimes ardour also segfaults after a period of > 5 min recording. However, many times with an existing session, I can record just fine for 4-5 minutes, save the session and exit. It is a somewhat random occurrence that I have not been able to exactly pin down. But the problem 0000001 seems to happen with new sessions. I am using 16 tracks of mono audio. I'm pretty sure this is an ardour-specific problem as the problems occur whether I am using my HDSP pci/multiface or the built-in AC97 sound OR a Matrox 450 or Radeon 9700 video card OR when compiling ardour from scratch or using the pre-packaged planetCCRMA binary OR using a stripped down service-free fluxbox system or xfce or gnome. The machine is a dual Xeon/Iwill mb/2GB RAM. I am using FC1/planetCCRMA. Ardour starts out at about 103MB of memory (using top) and grows at a rate of about 2MB/minute during recording. So I don't think these problems are related to the growing memory problem during recording that was reported earlier (are they?). Here is a backtrace for the freeze-up problem #2 described above. I haven't been able to get a backtrace for problem 0000001. (gdb) backtrace #0 0x085b88bf in SigC::ObjectScoped::invalid(bool) () 0000001 0x085b98fa in SigC::SlotDependent::Dep::erase() () #2 0x085b9389 in SigC::ScopeList::erase(SigC::ScopeIterator_) () #3 0x085b8373 in SigC::ObjectScoped::~ObjectScoped() () 0000004 0x083b6460 in StreamView::~StreamView() () 0000005 0x081c4f9d in AudioTimeAxisView::~AudioTimeAxisView() () #6 0x083adc2e in RouteUI::route_removed() () #7 0xbfffd940 in ?? () 0000008 0x08cc110c in ?? () 0000009 0xbfffd908 in ?? () 0000010 0x005b991a in ?? () 0000011 0x41e868f8 in ?? () My ardour.rc file contains these two lines: <Option name="minimum-disk-io-bytes" value="262144"/> <Option name="track-buffer-seconds" value="3.000000"/> --Neil | ||||
| Tags | No tags attached. | ||||
|
|
just for your information, this has been reported by a couple of other people. it has been extremely hard to get a good understanding of the problem - i.e. its not reproducable by most ardour users. it would be helpful if you could build a debuggable version of ardour, using cd .../top/of/your/ardour/source/tree make clean ./configure --disable-optimize <other args> make -j 2 (the -j 2 is optional but will speed up compilation). there's no guarantee that this will work any better for debugging than it has for others, but at least the backtraces will have a little more information. |
|
2005-03-08 08:42
|
|
|
|
[After compiling with --disable-optimize] I uploaded a file gdb.output containing the results of debugging with gdb. The session involved recording 16 tracks of mono audio until it hit about 8 to 9 minutes and the GUI froze. I ctl-C'ed in gdb and got the output in gdb.output after typing "thread apply all bt". Not sure what it all means. I am open to any clues or instructions. I've noticed that aftering compiling ardour with --disable-optimize it is harder to make it crash. Maybe there is an issue with some P4 (Xeon) optimizations. I knew I should have gone with an Athlon :). |
|
|
this looks similar to what i've been seeing. here's one lockup scenario, where the gui doesn't redraw. hopefully the logging will be self-explanatory: butler got the run butler transport work because transport_work_requested session_transport.cc BUTLER TRANSPORT WORK session_transport.cc non realtime stop session_transport.cc post TRANSPORT session_transport.cc post TRANSPORT work and stop session_events.cc set next event butler thread work butler paused butler thread work ..and there it stops. here's a backtrace after i killed Ardour with signal 11 (causing a core dump). it seems like everything is polling; #0 0x086f300d in SigC::Scopes::Extend::disconnect (this=0xada08798, l=true) at scope.cc:144 144 { (gdb) thread apply all bt Thread 7 (process 3139): #0 0xffffe410 in __kernel_vsyscall () 0000001 0x4cd4253e in do_sigwait () from /lib/tls/libpthread.so.0 #2 0x4cd425df in sigwait () from /lib/tls/libpthread.so.0 #3 0x0841191b in signal_thread (arg=0x0) at main.cc:134 0000004 0x4cd3c361 in start_thread () from /lib/tls/libpthread.so.0 0000005 0x4cbbdcbe in clone () from /lib/tls/libc.so.6 Thread 6 (process 3146): #0 0xffffe410 in __kernel_vsyscall () 0000001 0x4cbb40d4 in poll () from /lib/tls/libc.so.6 #2 0x086cf1d6 in ARDOUR::Source::peak_thread_work (arg=0x0) at source.cc:161 #3 0x4cd3c361 in start_thread () from /lib/tls/libpthread.so.0 0000004 0x4cbbdcbe in clone () from /lib/tls/libc.so.6 Thread 5 (process 3147): #0 0xffffe410 in __kernel_vsyscall () 0000001 0x4cbb40d4 in poll () from /lib/tls/libc.so.6 #2 0xb7fd4acc in jack_client_thread (arg=0x89c3840) at client.c:1076 #3 0x4cd3c361 in start_thread () from /lib/tls/libpthread.so.0 0000004 0x4cbbdcbe in clone () from /lib/tls/libc.so.6 Thread 4 (process 3148): #0 0xffffe410 in __kernel_vsyscall () 0000001 0x4cbb40d4 in poll () from /lib/tls/libc.so.6 #2 0x08671a0c in ARDOUR::Session::butler_thread_work (this=0x8bf0780) at session_butler.cc:189 #3 0x08671935 in ARDOUR::Session::_butler_thread_work (arg=0x8bf0780) at session_butler.cc:163 ---Type <return> to continue, or q <return> to quit--- 0000004 0x4cd3c361 in start_thread () from /lib/tls/libpthread.so.0 0000005 0x4cbbdcbe in clone () from /lib/tls/libc.so.6 Thread 3 (process 3149): #0 0xffffe410 in __kernel_vsyscall () 0000001 0x4cbb40d4 in poll () from /lib/tls/libc.so.6 #2 0x086a004f in ARDOUR::Session::midi_thread_work (this=0x8bf0780) at session_midi.cc:1238 #3 0x0869fddb in ARDOUR::Session::_midi_thread_work (arg=0x8bf0780) at session_midi.cc:1170 0000004 0x4cd3c361 in start_thread () from /lib/tls/libpthread.so.0 0000005 0x4cbbdcbe in clone () from /lib/tls/libc.so.6 Thread 2 (process 3150): #0 0xffffe410 in __kernel_vsyscall () 0000001 0x4cbb40d4 in poll () from /lib/tls/libc.so.6 #2 0x0869b5f1 in ARDOUR::Session::feedback_thread_work (this=0x8bf0780) at session_feedback.cc:141 #3 0x0869b53d in ARDOUR::Session::_feedback_thread_work (arg=0x8bf0780) at session_feedback.cc:116 0000004 0x4cd3c361 in start_thread () from /lib/tls/libpthread.so.0 0000005 0x4cbbdcbe in clone () from /lib/tls/libc.so.6 Thread 1 (process 3138): #0 0x086f300d in SigC::Scopes::Extend::disconnect (this=0xada08798, l=true) at scope.cc:144 0000001 0x086f29e1 in SigC::ObjectScoped::invalid (this=0xada08798, level=true) at ../sigc++/scope.h:216 #2 0x086f2c12 in ~ObjectScoped (this=0xada08798) at object.cc:48 #3 0x086f3979 in ~SlotData (this=0xada08798) at ../sigc++/slot.h:111 0000004 0x086f2ffc in SigC::Scopes::Extend::erase (this=0xb7511e28) at scope.cc:139 0000005 0x086f30d6 in SigC::ScopeList::erase (this=0xada087a0, pos=Cannot access memory at address 0x1 ) at scope.cc:224 #6 0x086f2917 in SigC::ObjectScoped::unregister_scope (this=0xada08798, scope=0xb7511e28) at ../sigc++/scope.h:250 ---Type <return> to continue, or q <return> to quit--- #7 0x086f2f32 in SigC::Scope::unregister_scope (this=0x877dbc8) at ../sigc++/scope.h:123 0000008 0x086f32b1 in ~Extend (this=0xb7511e28) at scope.cc:150 0000009 0x0826a1bf in ~Handle (this=0xb7511e28) at /home/nick/ardour/libs/sigc++/sigc++/slot.h:212 0000010 0x08270189 in ~Slot0 (this=0xb7511e28) at /usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/bits/stl_construct.h:107 0000011 0x0853798b in ~Request (this=0xb7511e18) at ./gtkmmext/gtk_ui.h:151 0000012 0x0853639c in Gtkmmext::UI::do_request (this=0x88cafe8, req=0xb7511e18) at gtk_ui.cc:420 0000013 0x08536183 in Gtkmmext::UI::handle_ui_requests (this=0x88cafe8) at gtk_ui.cc:359 0000014 0x085360d0 in Gtkmmext::UI::signal_pipe_callback (arg=0x88cafe8, fd=4, cond=GDK_INPUT_READ) at gtk_ui.cc:347 #15 0x4ce63290 in gdk_get_show_events () from /usr/lib/libgdk-1.2.so.0 0000016 0x088cafe8 in ?? () #17 0x00000004 in ?? () 0000018 0x4cdc3c4b in g_io_add_watch () from /usr/lib/libglib-1.2.so.0 0000019 0x4cdc5287 in g_get_current_time () from /usr/lib/libglib-1.2.so.0 0000020 0x4cdc5f13 in g_main_add_poll () from /usr/lib/libglib-1.2.so.0 0000021 0x4cdc60e5 in g_main_run () from /usr/lib/libglib-1.2.so.0 0000022 0x4d043232 in gtk_main () from /usr/lib/libgtk-1.2.so.0 0000023 0x0827180b in Gtk::Main::run () at /home/nick/ardour/libs/gtkmm/src/gtk--/main.h:168 #24 0x085358c6 in Gtkmmext::UI::run (this=0x88cafe8, old_receiver=@0x88b57c0) at gtk_ui.cc:168 0000025 0x084137f0 in main (argc=2, argv=0xbffff874) at main.cc:454 |
|
2005-03-08 22:57
|
|
|
|
i've caught some logging of handle_ui_requests as requested by paul. see the uploaded file lockup_log.typescript. |
|
|
hmm. that could have been jack kicking ardour, actually. sorry. i'll try to get the exact same lockup captured. |
|
|
just for future reference, it has been determined that this was *not* JACK kicking Ardour. |
|
|
current cvs seems to have fixed this |
|
|
With beta28 I have recorded several longish sessions with absolutely _no_ GUI freezes. Problem seems fixed. |
|
|
see bug history. terrible, terrible thread programming. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-03-04 22:27 | nklepeis | New Issue | |
| 2005-03-04 22:27 | nklepeis | => nklepeis@sbcglobal.net | |
| 2005-03-04 22:27 | nklepeis | Name | => Neil Klepeis |
| 2005-03-07 13:03 | paul | Note Added: 0002088 | |
| 2005-03-08 08:42 | nklepeis | File Added: gdb.output | |
| 2005-03-08 08:47 | nklepeis | Note Added: 0002097 | |
| 2005-03-08 08:54 | nklepeis | Note Edited: 0002097 | |
| 2005-03-08 18:44 | nmains | Note Added: 0002108 | |
| 2005-03-08 22:57 | nmains | File Added: lockup_log.typescript | |
| 2005-03-08 22:57 | nmains | Note Added: 0002109 | |
| 2005-03-08 23:05 | nmains | Note Added: 0002110 | |
| 2005-03-09 00:45 | nmains | Note Added: 0002112 | |
| 2005-03-09 17:15 | nmains | Note Added: 0002113 | |
| 2005-03-10 01:50 | paul | Relationship added | has duplicate 0000898 |
| 2005-03-10 21:32 | nklepeis | Note Added: 0002118 | |
| 2005-03-10 23:37 | paul | Status | new => resolved |
| 2005-03-10 23:37 | paul | Resolution | open => fixed |
| 2005-03-10 23:37 | paul | Assigned To | => paul |
| 2005-03-10 23:37 | paul | Note Added: 0002121 | |
| 2008-11-20 23:42 | seablade | Status | resolved => closed |
