View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000731 | ardour | bugs | public | 2004-10-06 02:08 | 2008-11-20 23:44 |
| Reporter | jwoithe | Assigned To | paul | ||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Summary | 0000731: Import external soundfile after auditioning freezes ardour | ||||
| Description | Create an stereo track. Right click and go to insert an external sndfile. Highlight a stereo soundfile and press the "play" (or "preview" or whatever that button is called). The audition happens as expected. Stop the audition and hit the button to do the import. Ardour freezes at this point. The dialog remains up but the application is unresponsive. Inserting the file without first auditioning it works fine. | ||||
| Additional Information | This is under Slackware 10.0 with ALSA 1.0.6a and Jack 0.99.0. Jack (and hense Ardour session) is 44.1kHz. Stereo file was 16 bit WAV format at 44.1kHz. | ||||
| Tags | No tags attached. | ||||
|
|
i can't duplicate this. |
|
|
I ran some further tests over the weekend and Ardour 0.9beta19 was definitely crashable on my system. I have, however, managed to narrow down the symptoms somewhat. Firstly, it is NOT necessary to audition a sndfile in order to trigger the crash. This probably clears ALSA/jack and the sound system in general. I noticed, however, that the crash did not occur all the time - I was probably crashing ardour about once every 2-3 insert operations. When it didn't crash ardour appeared to do the right thing. I noticed in my testing that there where in fact two different crashes which occurred. In the first, a thread dies but the main ardour process remains active (but does need to be manually killed since it becomes unresponsive). The thread which dies with a segfault has the next highest process id of the main ardour process. In other words, if ardour has pid 503, the thread which dies has pid 504. In this case the segfault occurs in sf_writef_double(). A gdb trace follows: #0 0x40420eb8 in sf_writef_double () from /usr/local/lib/libsndfile.so.1 0000001 0x4041d288 in sf_writef_double () from /usr/local/lib/libsndfile.so.1 #2 0x40415866 in sf_read_float () from /usr/local/lib/libsndfile.so.1 #3 0x0865f047 in ARDOUR::SndFileSource::read () at STTypes.h:48 0000004 0x0865ed6e in ARDOUR::SndFileSource::read_unlocked () at STTypes.h:48 0000005 0x086634f1 in ARDOUR::Source::do_build_peak () at STTypes.h:48 #6 0x08663077 in ARDOUR::Source::build_peaks () at STTypes.h:48 #7 0x086613d8 in ARDOUR::Source::peak_thread_work () at STTypes.h:48 0000008 0x4037acc4 in pthread_start_thread (arg=0xbf5ffbe0) at manager.c:300 0000009 0x406cc037 in clone () from /lib/libc.so.6 This crash occurs seemingly randomly when an sndfile is inserted. I see this crash when I simply wait for the insert operation to complete. If I do things while waiting (like close the insert dialog box) then the second crash (see below) is more likely. The second type of crash takes out the main ardour application. The tracebacks leading to the faulting function are much more varied in this case but they all appear to fault in mallopt(). The caller varies: I have seen: art_uta_from_irect() art_rect_list_from_uta() uta_union_clip() These crashes appear to be triggered when the insert dialog is moved (or in fact anything is done which causes an expose event of the main ardour window) while the insert operation is still in progress. Again, the crash is intermittant and happens perhaps once every 4-5 times I try. One of the shorter backtraces I have seen follows: #0 0x4066485e in mallopt () from /lib/libc.so.6 0000001 0x40663883 in malloc () from /lib/libc.so.6 #2 0x4040c1cb in art_uta_from_irect () from /usr/lib/libart_lgpl_2.so.2 #3 0x085009f8 in gtk_canvas_expose (widget=0x1f0, event=0x89f9520) at gtk-canva s.c:3094 0000004 0x08544593 in gtkmm_marshal_INT__POINTER (object=0x89f9520, func=0x8500880 < gtk_canvas_expose>, func_data=0x0, args=0x8bf6280) at marshal.cc:240 0000005 0x400dd19f in gtk_signal_set_funcs () from /usr/lib/libgtk-1.2.so.0 #6 0x400db234 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0 #7 0x40110fd9 in gtk_widget_event () from /usr/lib/libgtk-1.2.so.0 0000008 0x400ad7fc in gtk_main_do_event () from /usr/lib/libgtk-1.2.so.0 0000009 0x40155b44 in gdk_wm_protocols_filter () from /usr/lib/libgdk-1.2.so.0 0000010 0x40182e75 in g_get_current_time () from /usr/lib/libglib-1.2.so.0 0000011 0x4018332c in g_get_current_time () from /usr/lib/libglib-1.2.so.0 0000012 0x4018355c in g_main_run () from /usr/lib/libglib-1.2.so.0 0000013 0x400ad083 in gtk_main () from /usr/lib/libgtk-1.2.so.0 0000014 0x082471c1 in Gtk::Main::run () at main.h:168 #15 0x084dd12e in Gtkmmext::UI::run (this=0x8818f10, old_receiver=@0x880a260) at gtk_ui.cc:168 0000016 0x083ce6c0 in main () at newsavedialog.h:53 In case library versions are playing a part here, the following details the versions of all libraries in use by ardour on my PC: libgtk-1.2.so.0 1.2.10 libgdk-1.2.so.0 1.2.10 libgmodule-1.2.so.0 1.2.10 libglib-1.2.so.0 1.2.10 libdl.so.2 2.3.2 libXext.so.6 6.4 from xorg 6.8.1 libX11.so.6 6.2 from xorg 6.8.1 libjack.so.0 0.99.0 libxml2.so.2 2.6.9 libpthread.so.0 0.10 for glibc 2.3.2 libz.so.1 1.2.1.1 libm.so.6 2.3.2 libart_lgpl_2.so.2 2.3.16 libsndfile.so.1 1.0.9 liblrdf.so.2 0.3.7 libsamplerate.so.0 0.1.2 libasound.so.2 1.0.6 libstdc++.so.5 5.0.6 (gcc 3.3.4, glibc 2.3.2) libgcc_s.so.1 3.3.4 libc.so.6 2.3.2 /lib/ld-linux.so.2 ld 2.3.2 libraptor.so.1 1.3.2 The system is running Slackware 10.0 with Xorg upgraded to 6.8.1. All libraries were compiled using the stock compiler for that system (gcc 3.3.4). Other details: CPU: 550MHz Intel Pentium 3 (Katmai, stepping 3) RAM: 384MB + 128MB swap Soundcard: Ensoniq AudioPCI (ES1370) Jack command line: /usr/local/bin/jackstart -R -d alsa -d hw:0 -r 44100 -n 4 -p 512 Ardour configure command (I think): ./configure Finally, I have also been able to crash ardour by repeating an insert operation without closing the insert dialog. In other words, in the insert sndfile dialog, do: 1. choose a file, select "insert" 2. wait for insert operation to finish 3. return to step 1 |
|
|
Overnight I tested Ardour 0.9beta21 for this problem. The problem still occurs in the same way as previously detailed for 0.9beta19. The symptoms and overall behaviour haven't changed. The problem *might* be easier to trigger if you don't leave a lot of time between selecting a file to insert and hitting the insert button. As for 0.9beta19, the crash doesn't happen on every insert attempt under 0.9beta21. edited on: 12-07-04 15:32 |
|
|
Reminder sent to paul I don't want to be a pain and I know you're probably really busy trying to get 1.0 out the door, but I thought I'd just point out that on 17 Oct 2004 I added some more detailed feedback to this bug report including some backtraces from the crashes which may or may not prove useful. I would be more than happy to carry out more tests for you if it will help identify the problem. I could even do a short video of the screen showing the triggering of the bug if would assist you in your attempts to duplicate it. As per the note I added today, the problem persists in 0.9beta21. |
|
|
FYI: 0.9beta22 crashes in the same way as detailed for earlier versions. |
|
|
i have not forgotten this at all. i am definitely working on a related, perhaps identical, problem with linking/embedding external files. *actively* working on it, as in "most of today". the problem with your backtraces is that they simply show the signs of memory corruption in a totally post-facto way - i.e. they tell me something stomped on some memory it should not have, but there is no indication of when that happened - we are looking at the symptoms of it, not the cause. the only way to debug this kind of thing is to use valgrind, and if there is a race condition involved, the problem often vanishes when using valgrind. if you have valgrind installed, and want to try it out, let me know. |
|
|
Yes, I suspected that was the trouble with the backtraces - there was something about them which made me suspect some memory stomping was going on. I don't have valgrind installed but I am willing to give it a go to assist in tracking down this problem. I have valgrind 2.2.0 source which I might be able to install during this weekend - we'll see. In the meantime, I notice that 0.9beta23 is out with a couple of fixes to race conditions which might be the root cause of the troubles I'm seeing. I will get the 0.9beta23 code, try it out over the weekend and advise accordingly. |
|
|
I tried 0.9beta23 over the weekend. It was by no means an exhaustive test, but the indications are that the bug has been fixed in this version. Previously the crash would occur on my system after inserting no more than 4 stereo files into a session (ie: it could happen earlier but by the 4th you were more or less assured of triggering the bug). Under 0.9beta23 I successfully inserted 8 stereo files into each of two sessions without a crash occuring. I will run some more tests in the next few days but at this stage it looks likely that the bug has been squashed. |
|
|
see bugnotes for history. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-10-06 02:08 | jwoithe | New Issue | |
| 2004-10-06 02:08 | jwoithe | => jwoithe@physics.adelaide.edu.au | |
| 2004-10-06 02:08 | jwoithe | Name | => Jonathan Woithe |
| 2004-10-13 18:43 | paul | Note Added: 0001502 | |
| 2004-10-13 18:43 | paul | Status | new => feedback |
| 2004-10-18 02:06 | jwoithe | Note Added: 0001527 | |
| 2004-12-07 23:24 | jwoithe | Note Added: 0001677 | |
| 2004-12-07 23:31 | jwoithe | Note Added: 0001678 | |
| 2004-12-07 23:32 | jwoithe | Note Edited: 0001677 | |
| 2005-01-05 22:52 | jwoithe | Note Added: 0001806 | |
| 2005-01-05 22:53 | jwoithe | Note Edited: 0001806 | |
| 2005-01-06 00:14 | paul | Note Added: 0001808 | |
| 2005-01-07 03:03 | jwoithe | Note Added: 0001810 | |
| 2005-01-07 03:05 | jwoithe | Note Edited: 0001810 | |
| 2005-01-09 22:38 | jwoithe | Note Added: 0001815 | |
| 2005-01-15 15:10 | paul | Status | feedback => resolved |
| 2005-01-15 15:10 | paul | Resolution | open => fixed |
| 2005-01-15 15:10 | paul | Assigned To | => paul |
| 2005-01-15 15:10 | paul | Note Added: 0001859 | |
| 2008-11-20 23:44 | seablade | Status | resolved => closed |
