[ardour-dev] Mantis Bug 655 - Panner States/Dodgy XML/Ardour Crashes
Dan Harper
tech at danharper.org
Sun Sep 5 18:41:46 PDT 2004
Here is some more interesting info and a bit of a rant regarding the
reliability of Ardour that I've just pecked into Mantis, but this looks
to be a serious issue in Ardour that I think should be discussed:
OK, here is some more info. It seems to be a problem with panner
states.
This issue has had several effects. Initially I was unable to open the
session, the Ardour log showed something like:
[ERROR]: Unknown connection "0x8cc3b98" listed for input of Bass
as previously, except the hex value and track was different as it is a
different sesison.
Then I tried 3 or 4 times to open it, eventually it did open.
Now the track in question had no outputs assigned, similar to when the
problem appeared in the previous problem sessions. I decided to leave
it as is for a while, and messed around with some other things. I saved
the session and then exited, everything seemed fine. Now I could open
and close the session with no problems and no errors, except the problem
with the outputs on that particular track was still present. So I
decided to add the outputs back. I added one, fine. Then when I added
the second, the crash occurred again.
Now when I try to open the session, X locks up, I needed to go to
another terminal to kill ardour, jack and qjackctl.
I rebuilt the latest CVS with dev build and no optimisation. And tested
in gdb. X locked again. Killed it all and tried again. This time the
session opened, and I see this in my terminal:
[dharper at laptank ardour-cvs-04-openfix]$ gdb gtk_ardour/ardour
GNU gdb Red Hat Linux (5.3.90-0.20030710.41rh)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host
libthread_db library "/lib/libthread_db.so.1".
(gdb) run
Starting program:
/home/dharper/downloads/ardour-cvs-04-openfix/gtk_ardour/ardour
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 31859)]
[New Thread 32769 (LWP 31860)]
[New Thread 16386 (LWP 31861)]
Ardour/GTK 0.531.1 running with libardour 0.830.0
Loading UI configuration file /home/dharper/.ardour/ardour_ui.rc
Loading system configuration file /home/dharper/.ardour/ardour_system.rc
Loading user configuration file /home/dharper/.ardour/ardour.rc
ardour: [WARNING]: No MMC control (MIDI port "hw:0" not available)
file_set_error: No such device or address
[New Thread 32771 (LWP 31865)]
[New Thread 49156 (LWP 31866)]
Use of deprecated SAXv1 function internalSubset
ardour: [INFO]: detecting VST plugins along
/usr/local/lib/vst:/usr/lib/vst
ardour: [WARNING]: Your system generates "Mod2" when the NumLock key is
pressed. This can cause problems when editing so Ardour will use Mod3 to
mean Meta rather than Mod2
ardour: [ERROR]: KeyboardTarget: unknown action
"edit-cursor-to-selection-start"
ardour: [ERROR]: KeyboardTarget: unknown action
"edit-cursor-to-selection-end"
ardour: [ERROR]: KeyboardTarget: unknown action "set-mouse-mode-scrub"
ardour: [ERROR]: KeyboardTarget: unknown action "start-selection"
ardour: [ERROR]: KeyboardTarget: unknown action "finish-selection"
ardour: [ERROR]: KeyboardTarget: unknown action
"extend-selection-to-end-of-region"
ardour: [ERROR]: KeyboardTarget: unknown action
"extend-selection-to-start-of-region"
ardour: [ERROR]: KeyboardTarget: unknown action "duplicate-selection"
ardour: [ERROR]: KeyboardTarget: unknown action "split-region"
[New Thread 65541 (LWP 31867)]
[New Thread 81926 (LWP 31868)]
Loading session /home/dharper/audio/Melissa_p-20040904 using snapshot
Melissa_p-20040904
[New Thread 98311 (LWP 31869)]
[New Thread 114696 (LWP 31870)]
finished route resort
master
finished route resort
master MelGuitarMic
finished route resort
master MelGuitarMic RozVox
finished route resort
master MelGuitarMic RozVox JuliaPerc
finished route resort
master MelGuitarMic RozVox JuliaPerc StephPerc
finished route resort
master MelGuitarMic RozVox JuliaPerc StephPerc MelGuitarPickup
finished route resort
master MelGuitarMic RozVox JuliaPerc StephPerc MelGuitarPickup MelVox
finished route resort
master MelGuitarMic RozVox JuliaPerc StephPerc MelGuitarPickup MelVox
DanPodR
finished route resort
master MelGuitarMic RozVox JuliaPerc StephPerc MelGuitarPickup MelVox
DanPodR Audio 8
finished route resort
master MelGuitarMic RozVox JuliaPerc StephPerc MelGuitarPickup MelVox
DanPodR Audio 8 Reverb
finished route resort
master MelGuitarMic RozVox JuliaPerc StephPerc MelGuitarPickup MelVox
DanPodR Audio 8 Reverb
finished route resort
master MelGuitarMic RozVox JuliaPerc StephPerc MelGuitarPickup MelVox
DanPodR Audio 8 Reverb
finished route resort
MelGuitarMic RozVox JuliaPerc Audio 8 Reverb master StephPerc
MelGuitarPickup MelVox DanPodR
Which looks OK so far.
I go to add that dreaded second input and get this:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 81926 (LWP 31868)]
0x085b3bde in ARDOUR::IO::pan(std::vector<float*, std::allocator<float*>
>&, unsigned long, unsigned, unsigned, float) () at xml++.cc:12
12 XMLTree::XMLTree()
Current language: auto; currently c++
(gdb)
Ah ha! The problem seems related to panner code. One thing here that I
always suspected... Why is the code referencing XML? I haven't decided
to save my session file, so why is Ardour worried about XML? I've
noticed the following about Ardour that concerns me:
1. Sometimes if Ardour crashes while I'm in the middle of something,
some changes that I've made since the last save have actually appeared
in the session file. But I haven't saved those changes! Ardour seesm
to automatically save the session at certain points. It worries me,
because if I'm trying something out I don't want to save yet (I want to
be sure it works) then I don't want Ardour being a smart aleck and
saving these changes before I'm comfortable to commit to my precious
session file. (Editing can take a long time, don't increase the risk of
me doing it all over again!)
2. The XML code (which is a library no?) is very unstable. I've always
noticed Ardour having the most problems saving or loading a session
file. I don't think that whizz-bang features are a priority while
Ardour cannot even reliably save and open a session file. There is no
verification that Ardour has properly saved the XML file. And the
response to an error loading an XML file is commonly a segfault.
3. Bugs like this now become complex to track down due to Ardour
playing with XML when I'm trying to add a port. I'm not trying to save
a session, so don't make me! I think because of the instability of the
XML code, and because Ardour plays with it far too often outside of
opening and saving a file, it causes many instabilities in Ardour.
Anyway, here is the trace:
(gdb) thread apply all bt
Thread 9 (Thread 114696 (LWP 31870)):
#0 0x4110e6fa in poll () from /lib/i686/libc.so.6
#1 0x086358e7 in ARDOUR::Session::midi_thread_work() () at xml++.cc:12
#2 0x086356e5 in ARDOUR::Session::_midi_thread_work(void*) () at
xml++.cc:12
#3 0x412a9db2 in pthread_start_thread () from /lib/i686/libpthread.so.0
#4 0x412a9f45 in pthread_start_thread_event () from
/lib/i686/libpthread.so.0
#5 0x4111779a in clone () from /lib/i686/libc.so.6
Thread 8 (Thread 98311 (LWP 31869)):
#0 0x412ac0b4 in __pthread_sigsuspend () from /lib/i686/libpthread.so.0
#1 0x412ab9f8 in __pthread_wait_for_restart_signal () from
/lib/i686/libpthread.so.0
#2 0x00000020 in ?? ()
Thread 7 (Thread 81926 (LWP 31868)):
#0 0x085b3bde in ARDOUR::IO::pan(std::vector<float*,
std::allocator<float*> >&, unsigned long, unsigned, unsigned, float) ()
at xml++.cc:12
#1 0x085fde51 in
ARDOUR::Route::process_output_buffers(std::vector<float*,
std::allocator<float*> >&, unsigned long, unsigned, unsigned, unsigned,
unsigned, bool, int, bool) () at xml++.cc:12
#2 0x085728d9 in ARDOUR::AudioTrack::passthru_silence(unsigned,
unsigned, unsigned, unsigned, int) ()
at xml++.cc:12
#3 0x08572a71 in ARDOUR::AudioTrack::no_roll(unsigned, unsigned,
unsigned, unsigned, bool, bool, bool) ()
at xml++.cc:12
#4 0x08637e7b in ARDOUR::Session::no_roll(unsigned, unsigned) () at
xml++.cc:12
#5 0x08638eb3 in ARDOUR::Session::process_without_events(unsigned) ()
at xml++.cc:12
#6 0x0863855b in ARDOUR::Session::process_with_events(unsigned) () at
xml++.cc:12
#7 0x08637c4f in ARDOUR::Session::process(unsigned) () at xml++.cc:12
#8 0x08552072 in ARDOUR::AudioEngine::process_callback(unsigned) () at
xml++.cc:12
#9 0x08551d22 in ARDOUR::AudioEngine::_process_callback(unsigned,
void*) () at xml++.cc:12
#10 0x41b8036a in jack_port_type_size () from /usr/lib/libjack.so.0
#11 0x00000400 in ?? ()
#12 0x08920608 in ?? ()
#13 0x0000063a in ?? ()
Thread 6 (Thread 65541 (LWP 31867)):
#0 0x412ac0b4 in __pthread_sigsuspend () from /lib/i686/libpthread.so.0
#1 0x412ab9f8 in __pthread_wait_for_restart_signal () from
/lib/i686/libpthread.so.0
#2 0x00000020 in ?? ()
Thread 5 (Thread 49156 (LWP 31866)):
#0 0x412af15b in read () from /lib/i686/libpthread.so.0
#1 0x40d23e24 in ?? () from /usr/lib/wine/ntdll.dll.so
Thread 4 (Thread 32771 (LWP 31865)):
#0 0x412af15b in read () from /lib/i686/libpthread.so.0
#1 0x4003249c in __JCR_LIST__ () from /usr/local/lib/libfst.so
Thread 3 (Thread 16386 (LWP 31861)):
#0 0x41062c1b in sigsuspend () from /lib/i686/libc.so.6
#1 0x412ac506 in sigwait () from /lib/i686/libpthread.so.0
#2 0x083cf485 in signal_thread(void*) () at xml++.cc:12
#3 0x412a9db2 in pthread_start_thread () from /lib/i686/libpthread.so.0
#4 0x412a9f45 in pthread_start_thread_event () from
/lib/i686/libpthread.so.0
#5 0x4111779a in clone () from /lib/i686/libc.so.6
Thread 2 (Thread 32769 (LWP 31860)):
#0 0x4110e6fa in poll () from /lib/i686/libc.so.6
#1 0x412a8d1a in __pthread_manager () from /lib/i686/libpthread.so.0
#2 0x412a8fea in __pthread_manager_event () from
/lib/i686/libpthread.so.0
#3 0x4111779a in clone () from /lib/i686/libc.so.6
Thread 1 (Thread 16384 (LWP 31859)):
#0 0x4110e6fa in poll () from /lib/i686/libc.so.6
#1 0x414bedcb in g_main_is_running () from /usr/lib/libglib-1.2.so.0
#2 0x414be685 in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#3 0x414beaf4 in g_main_run () from /usr/lib/libglib-1.2.so.0
#4 0x417a46af in gtk_main () from /usr/lib/libgtk-1.2.so.0
#5 0x08249cf1 in Gtk::Main::run() () at main.h:168
#6 0x084e2d4e in Gtkmmext::UI::run(Receiver&) (this=0x881f610,
old_receiver=@0x880c160) at gtk_ui.cc:168
#7 0x083d0a8d in main () at xml++.cc:12
0x085b3bde 12 XMLTree::XMLTree()
On Mon, 2004-09-06 at 09:30, Dan Harper wrote:
> Hi all,
>
> I've been trying to track down information on a bug that I'm being
> bitten by constantly, and was wondering if anyone can confirm the latest
> interesting info that I've found.
>
> You can of course read the history of this bug here:
> http://www.ardour.org/mantis/bug_view_page.php?bug_id=0000655
> but, here is the latest.
>
> It seems that if I create a session with Jack using my HDSP CardBus
> interface, the session will open and close fine, no problems. But, when
> I open this same session with Jack using my internal Intel sound chip on
> the laptop, Ardour will crash on opening the session, or it will open
> without connecting some tracks to outputs and crashes on attempting to
> re-connect them.
>
> It seems that Jack gets upset here also, so it could actually be a Jack
> bug, I'm not entirely sure yet.
>
> Can anyone with a similar setup test this out and see if the problem can
> be reproduced? It would help out greatly.
>
> Thanks,
> Dan
--
Dan Harper
http://danharper.org
More information about the Ardour-Dev
mailing list