Bug#584605: audacity: Continuing to backtrace
Dave Witbrodt
Version: 1.3.12-3+fix03
Severity: normal
Forgive the version listed above: it is from my local build, and is obviously
not an official Debian package.
After applying the patch suggested, I was getting a FTBFS:
----------
[...]
g++ -c -g -O2 -g -Wall -O2 -I../lib-src/portmixer/include -I../lib-src/portaudio-v19/include -g -O2 -g -Wall -O2 -Wall -I/usr/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -I../lib-src/FileDialog -g -O2 -Wall -I/home/dawitbro/sandbox/audacity/audacity-1.3.12/lib-src/lib-widget-extra -I../lib-src/sbsms/include -I/usr/include/soundtouch -I../lib-src/libnyquist -g -O2 -Wall -I/home/dawitbro/sandbox/audacity/audacity-1.3.12/lib-src/portsmf -fno-strict-aliasing -I./include -I. -DLIBDIR=\"/usr/lib\" -D__STDC_CONSTANT_MACROS -Wall -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 FFmpeg.cpp -o FFmpeg.o
FFmpeg.cpp:257: error: invalid conversion from ‘int (*)(URLContext*, unsigned char*, int)’ to ‘int (*)(URLContext*, const unsigned char*, int)’
make[2]: *** [FFmpeg.o] Error 1
make[2]: Leaving directory `/home/dawitbro/sandbox/audacity/audacity-1.3.12/src'
make[1]: *** [audacity] Error 2
make[1]: Leaving directory `/home/dawitbro/sandbox/audacity/audacity-1.3.12'
make: *** [debian/stamp-makefile-build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
----------
The error was indicating the closing brace of this block of code:
$ grep -n -A 7 "URLProtocol ufile_protocol" src/FFmpeg.cpp
250:URLProtocol ufile_protocol = {
251- "ufile",
252- ufile_open,
253- ufile_read,
254- ufile_write,
255- ufile_seek,
256- ufile_close,
257-};
Clearly there was some sort of type mismatch, so I looked around for
a while. I thought I had found the definition of "URLProtocol" here:
$ grep -A 12 "typedef struct URLProtocol" lib-src/ffmpeg/libavformat/avio.h
typedef struct URLProtocol {
const char *name;
int (*url_open)(URLContext *h, const char *filename, int flags);
int (*url_read)(URLContext *h, unsigned char *buf, int size);
int (*url_write)(URLContext *h, unsigned char *buf, int size);
int64_t (*url_seek)(URLContext *h, int64_t pos, int whence);
int (*url_close)(URLContext *h);
struct URLProtocol *next;
int (*url_read_pause)(URLContext *h, int pause);
int64_t (*url_read_seek)(URLContext *h, int stream_index,
int64_t timestamp, int flags);
int (*url_get_file_handle)(URLContext *h);
} URLProtocol;
And the prototypes which might match the 'make' error above are "url_open",
"url_read", and "url_write"; these correspond to ufile_open(), ufile_read(),
and ufile_write() in src/FFmpeg.cpp:
$ egrep -n 'int ufile_(open|read|write)' src/FFmpeg.cpp
170:static int ufile_open(URLContext *h, const char *filename, int flags)
198:static int ufile_read(URLContext *h, unsigned char *buf, int size)
207:static int ufile_write(URLContext *h, unsigned char *buf, int size)
I couldn't SEE any problem to cause 'make' to fail here. After about an hour
it dawned on me that 'audacity' seems to be shipping its own FFMPEG code, but
that the Debian sources for 'audacity' build-depend on an external FFMPEG.
***************
*** WARNING ***
The following discussion must be understood in the context of the packages
on my system. I believe that I am using FFMPEG from debian-multimedia.org:
$ apt-cache policy libavformat52
libavformat52:
Installed: 5:0.6~svn20100603-0.0
Candidate: 5:0.6~svn20100603-0.0
Version table:
*** 5:0.6~svn20100603-0.0 0
990 http://mirror.csclub.uwaterloo.ca unstable/main Packages
100 /var/lib/dpkg/status
4:0.6~svn20100505-1 0
350 http://debian.osuosl.org experimental/main Packages
4:0.5.2-1 0
990 http://debian.osuosl.org unstable/main Packages
If this is a critical issue in terms of dealing with this bug, please let
me know what changes to make in my local builds, or whether to cancel the
bug report entirely. So far, I am seeing evidence of real bugs in the
audacity source code, before external FFMPEG libraries are even involved.
*** END WARNING ***
*******************
Once I realized that the build was being made against the external FFMPEG,
I looked around at the listing of build dependencies and eventually
discovered this:
$ grep -Rn -A 12 "typedef struct URLProtocol" /usr/include/libavformat/avio.h
223:typedef struct URLProtocol {
224- const char *name;
225- int (*url_open)(URLContext *h, const char *url, int flags);
226- int (*url_read)(URLContext *h, unsigned char *buf, int size);
227- int (*url_write)(URLContext *h, const unsigned char *buf, int size);
228- int64_t (*url_seek)(URLContext *h, int64_t pos, int whence);
229- int (*url_close)(URLContext *h);
230- struct URLProtocol *next;
231- int (*url_read_pause)(URLContext *h, int pause);
232- int64_t (*url_read_seek)(URLContext *h, int stream_index,
233- int64_t timestamp, int flags);
234- int (*url_get_file_handle)(URLContext *h);
235-} URLProtocol;
Compare line 227 here with the corresponding "url_write" line above, and
you will see that the external FFMPEG library has added "const" to the
second argument.
I patched my local 'audacity' sources this way:
----------
$ cat fix-ufile_write-definition.patch
--- a/src/FFmpeg.cpp 2010-06-13 15:28:16.000000000 -0400
+++ b/src/FFmpeg.cpp 2010-06-13 15:56:16.000000000 -0400
@@ -204,7 +204,7 @@
return ret;
}
-static int ufile_write(URLContext *h, unsigned char *buf, int size)
+static int ufile_write(URLContext *h, const unsigned char *buf, int size)
{
return (int) ((wxFile *) h->priv_data)->Write(buf, size);
}
----------
The build succeed after that.
Unfortunately, 'audacity' was still having problems after trying to run
the locally patched version:
----------
(gdb) bt
#0 0x00007ffff2865166 in ?? () from /lib/libc.so.6
#1 0x00007ffff37a1630 in snd_mixer_find_selem () from /usr/lib/libasound.so.2
#2 0x000000000085e656 in open_mixer (dev=0xfc9990, card=<value optimized out>, playback=<value optimized out>) at src/px_linux_alsa.c:180
#3 0x000000000085ea77 in OpenMixer_Linux_ALSA (Px=0xfc7d50, index=<value optimized out>) at src/px_linux_alsa.c:296
#4 0x000000000085d1e3 in Px_OpenMixer (pa_stream=0xfc6ba0, i=0) at src/px_mixer.c:155
#5 0x000000000051d23f in AudioIO::HandleDeviceChange (this=0xe86130) at AudioIO.cpp:573
#6 0x000000000051d774 in AudioIO (this=0xe86130) at AudioIO.cpp:351
#7 0x000000000051d874 in InitAudioIO () at AudioIO.cpp:216
#8 0x0000000000517342 in AudacityApp::OnInit (this=0xddb2c0) at AudacityApp.cpp:1057
#9 0x00007ffff6d1c632 in wxEntry(int&, wchar_t**) () from /usr/lib/libwx_baseu-2.8.so.0
#10 0x0000000000512f02 in main (argc=1, argv=0x7fffffffdb10) at AudacityApp.cpp:626
----------
It is now failing at a different location in the same file:
lib-src/portmixer/src/px_linux_alsa.c
This is the section of the function open_mixer() where the program dies:
----------
static int open_mixer(PxDev *dev, int card, int playback)
{
[...]
i = 0;
for (elem = snd_mixer_first_elem(dev->handle);
elem != NULL;
elem = snd_mixer_elem_next(elem))
{
snd_mixer_elem_t *vol;
int ndx;
if (playback) {
if (snd_mixer_selem_has_common_volume(elem) ||
snd_mixer_selem_has_playback_volume(elem)) {
snprintf(name,
sizeof(name),
"%s:%d",
snd_mixer_selem_get_name(elem),
snd_mixer_selem_get_index(elem));
dev->selems[i].elem = elem;
dev->selems[i].index = snd_mixer_selem_get_index(elem);
dev->selems[i].name = strdup(name);
if (!dev->selems[i].name) {
break;
}
i++;
}
continue;
}
snd_mixer_selem_id_set_name(sid, "Capture");
snd_mixer_selem_id_set_index(sid, snd_mixer_selem_get_index(elem));
* vol = snd_mixer_find_selem(dev->handle, sid);
[...]
----------
Line 180, where the segfault occurs, is the last line printed here, the
call to snd_mixer_find_selem() [marked with *]. We have arrived here
from line 296 of the same file [marked with * below]:
----------
int OpenMixer_Linux_ALSA(px_mixer *Px, int index)
{
PxInfo *info;
int card;
if (!initialize(Px)) {
return FALSE;
}
info = (PxInfo *) Px->info;
if (PaAlsa_GetStreamInputCard(Px->pa_stream, &card) == paNoError) {
* if (!open_mixer(&info->capture, card, FALSE)) {
return cleanup(Px);
}
}
if (PaAlsa_GetStreamOutputCard(Px->pa_stream, &card) == paNoError) {
if (!open_mixer(&info->playback, card, TRUE)) {
return cleanup(Px);
}
}
return TRUE;
}
----------
Reviewing, it looks like OpenMixer_Linux_ALSA() calls open_mixer() with an
address where information can be stored, a card #, and a third argument of
FALSE (which apparently corresponds to Capture instead of Playback devices).
Once inside open_mixer(), the function runs until it arrives at the "for"
loop reproduced above. The value of "i" is set to 0, the "if (playback)"
block is skipped ("playback" was the 3rd parameter of the function, which
was called with FALSE), and we hit these lines ...
snd_mixer_selem_id_set_name(sid, "Capture");
snd_mixer_selem_id_set_index(sid, snd_mixer_selem_get_index(elem));
vol = snd_mixer_find_selem(dev->handle, sid);
... where the segfault occurs. Something else is puzzling me now, and it has
to do with the value of "i". The full backtrace looks like this:
----------
(gdb) bt full
#0 0x00007ffff2865166 in ?? () from /lib/libc.so.6
No symbol table info available.
#1 0x00007ffff37a1630 in snd_mixer_find_selem () from /usr/lib/libasound.so.2
No symbol table info available.
#2 0x000000000085e656 in open_mixer (dev=0xfc9990, card=<value optimized out>, playback=<value optimized out>) at src/px_linux_alsa.c:180
vol = 0x0
err = <value optimized out>
i = 530
elem = 0xfea050
name = "DSP 31:0\000F Right:0\000\000\000\000\000\000\242\001\205\000\000\000\000\000\001\000\000\000\000\000\000\000\003", '\000' <repeats 15 times>"\254, \003\000\000\000\000\000\000\001\000\000\000\377\177\000\000@\232Q", '\000' <repeats 13 times>"\220, \336\377\377\377\177\000\000\240n\374\000\000\000\000\000\000\000\000\000\200\210\345@\001\000\000\000\001\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000`\000\000\000\000\000\000\000p\335\377\377\377\177\000\000\250~\264\362\377\177\000\000H\263g\256\031Τ?P\000\000\000\000\000\000\000\260\335\377\377\006\000\000\000h~\264\362\377\177\000\000\003\000\000\000\000\000\000\000\360\000\000\000\000\000\000\000\230~\264\362\377\177\000\000P}\374\000\000\000\000\000PJ\002\000\000\000\000\000\260\325\375\000\000\000\000\000P\000\000\000\000\000\000\000J\252\204\000\000\000\000"
#3 0x000000000085ea77 in OpenMixer_Linux_ALSA (Px=0xfc7d50, index=<value optimized out>) at src/px_linux_alsa.c:296
card = 0
#4 0x000000000085d1e3 in Px_OpenMixer (pa_stream=0xfc6ba0, i=0) at src/px_mixer.c:155
good = <value optimized out>
#5 0x000000000051d23f in AudioIO::HandleDeviceChange (this=0xe86130) at AudioIO.cpp:573
recDeviceNum = <value optimized out>
stream = 0xfc6ba0
playDeviceNum = <value optimized out>
numrates = <value optimized out>
highestSampleRate = <value optimized out>
error = 0
playbackParameters = {device = 26, channelCount = 1, sampleFormat = 1, suggestedLatency = 0.042653061224489794, hostApiSpecificStreamInfo = 0x0}
captureParameters = {device = 0, channelCount = 1, sampleFormat = 1, suggestedLatency = 0.011609977324263039, hostApiSpecificStreamInfo = 0x0}
inputVol = 0
#6 0x000000000051d774 in AudioIO (this=0xe86130) at AudioIO.cpp:351
err = <value optimized out>
#7 0x000000000051d874 in InitAudioIO () at AudioIO.cpp:216
No locals.
#8 0x0000000000517342 in AudacityApp::OnInit (this=0xddb2c0) at AudacityApp.cpp:1057
future1 = {<wxStringBase> = {static npos = 18446744073709551615, m_pchData = 0xde9a18 L"Master Gain Control"}, <No data fields>}
lang = {<wxStringBase> = {static npos = 18446744073709551615, m_pchData = 0xe878e8 L"en"}, <No data fields>}
pWnd = <value optimized out>
appName = {<wxStringBase> = {static npos = 18446744073709551615, m_pchData = 0xde9938 L"audacity"}, <No data fields>}
future2 = {<wxStringBase> = {static npos = 18446744073709551615, m_pchData = 0xddb748 L"Input Meter"}, <No data fields>}
home = {<wxStringBase> = {static npos = 18446744073709551615, m_pchData = 0xdeb118 L"/home/dawitbro"}, <No data fields>}
pathVar = {<wxStringBase> = {static npos = 18446744073709551615, m_pchData = 0x7ffff6d98678 L""}, <No data fields>}
tmpFile = {m_volume = {<wxStringBase> = {static npos = 18446744073709551615, m_pchData = 0x7ffff6d98678 L""}, <No data fields>}, m_dirs = {m_nSize = 16, m_nCount = 1, m_pItems = 0xe82610,
m_autoSort = false}, m_name = {<wxStringBase> = {static npos = 18446744073709551615, m_pchData = 0xe81bf8 L"nnHRM19Y"}, <No data fields>}, m_ext = {<wxStringBase> = {
static npos = 18446744073709551615, m_pchData = 0x7ffff6d98678 L""}, <No data fields>}, m_relative = false, m_hasExt = false}
project = <value optimized out>
vendorName = {<wxStringBase> = {static npos = 18446744073709551615, m_pchData = 0xde99a8 L"audacity"}, <No data fields>}
future3 = {<wxStringBase> = {static npos = 18446744073709551615, m_pchData = 0xde9ac8 L"Output Meter"}, <No data fields>}
tmpDirLoc = {<wxStringBase> = {static npos = 18446744073709551615, m_pchData = 0xe81cf8 L"/tmp"}, <No data fields>}
didRecoverAnything = <value optimized out>
#9 0x00007ffff6d1c632 in wxEntry(int&, wchar_t**) () from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#10 0x0000000000512f02 in main (argc=1, argv=0x7fffffffdb10) at AudacityApp.cpp:626
No locals.
----------
In stack frame #2, we clearly have a value of 530 in "i". When did
that happen, since last we saw "i" was just set to 0?
This must mean that the "for" loop has iterated 529 times, and
dies the 530th time. I'm not sure if that's bad or good. Quite
frankly, I can't pretend to understand this code. In my view,
open_mixer() ought to be rewritten using some helper functions
to decrease the size of the code. However, I am also unfamiliar
with these ALSA library data structures and functions, so there
was never much chance I could understand it in the first place.
Hopefully someone on the Debian Multimedia Maintainers team can make
sense out of this, or it is headed upstream.
In case it helps, here is what 'aplay' detects for my hardware:
$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: EMU0404 [E-mu 0404b PCI [MAEM8852]], device 0: emu10k1 [ADC Capture/Standard PCM Playback]
Subdevices: 32/32
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
Subdevice #7: subdevice #7
Subdevice #8: subdevice #8
Subdevice #9: subdevice #9
Subdevice #10: subdevice #10
Subdevice #11: subdevice #11
Subdevice #12: subdevice #12
Subdevice #13: subdevice #13
Subdevice #14: subdevice #14
Subdevice #15: subdevice #15
Subdevice #16: subdevice #16
Subdevice #17: subdevice #17
Subdevice #18: subdevice #18
Subdevice #19: subdevice #19
Subdevice #20: subdevice #20
Subdevice #21: subdevice #21
Subdevice #22: subdevice #22
Subdevice #23: subdevice #23
Subdevice #24: subdevice #24
Subdevice #25: subdevice #25
Subdevice #26: subdevice #26
Subdevice #27: subdevice #27
Subdevice #28: subdevice #28
Subdevice #29: subdevice #29
Subdevice #30: subdevice #30
Subdevice #31: subdevice #31
card 0: EMU0404 [E-mu 0404b PCI [MAEM8852]], device 2: emu10k1 efx [Multichannel Capture/PT Playback]
Subdevices: 8/8
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
Subdevice #7: subdevice #7
card 0: EMU0404 [E-mu 0404b PCI [MAEM8852]], device 3: emu10k1 [Multichannel Playback]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: SB [HDA ATI SB], device 0: ALC889 Analog [ALC889 Analog]
Subdevices: 0/1
Subdevice #0: subdevice #0
card 1: SB [HDA ATI SB], device 1: ALC889 Digital [ALC889 Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: HDMI [HDA ATI HDMI], device 3: ATI HDMI [ATI HDMI]
Subdevices: 1/1
Subdevice #0: subdevice #0
(At this point, it would be appropriate if someone could change the
title of this bug in the BTS, since the complaint about JACK not
running had nothing to do with the problem. I don't know my way
around the BTS well enough, yet, to do that -- not even sure if I
have the permissions to do it.)
HTH,
Dave W.
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Reinhard Tartler
Thank you for your very extensive analysis.
On Mon, Jun 14, 2010 at 00:11:08 (CEST), Dave Witbrodt wrote:
> The following discussion must be understood in the context of the packages
> on my system. I believe that I am using FFMPEG from debian-multimedia.org:
>
> $ apt-cache policy libavformat52
> libavformat52:
> Installed: 5:0.6~svn20100603-0.0
> Candidate: 5:0.6~svn20100603-0.0
> Version table:
> *** 5:0.6~svn20100603-0.0 0
> 990 http://mirror.csclub.uwaterloo.ca unstable/main Packages
> 100 /var/lib/dpkg/status
> 4:0.6~svn20100505-1 0
> 350 http://debian.osuosl.org experimental/main Packages
> 4:0.5.2-1 0
> 990 http://debian.osuosl.org unstable/main Packages
>
> If this is a critical issue in terms of dealing with this bug, please let
> me know what changes to make in my local builds, or whether to cancel the
> bug report entirely. So far, I am seeing evidence of real bugs in the
> audacity source code, before external FFMPEG libraries are even involved.
> *** END WARNING ***
> *******************
I think this is the criticial issue for this bug. However, I'm pretty
confident that this will happen with the ffmpeg version from
experimental as well.
You are doing excellent (upstream) work, which should definitly go in
upstream. May I suggest to forward this analysis upstream, and ask them
to confirm that audacity works against a copy of ffmpeg from the 0.6
branch: `svn export svn://svn.ffmpeg.org/ffmpeg/branches/0.6`
I expect to release 0.6 this week, and will then upload "final" 0.6
packages to debian/experimental and ubuntu/maverick.
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
Adrian Knoth
> * vol = snd_mixer_find_selem(dev->handle, sid);
> i = 530
> In stack frame #2, we clearly have a value of 530 in "i". When did
> that happen, since last we saw "i" was just set to 0?
Weird.
> This must mean that the "for" loop has iterated 529 times, and
> dies the 530th time. I'm not sure if that's bad or good. Quite
Me neither.
I just read the code. Just an idea, everything is theoretical, given
that this seems to be local to your system:
The last fix was about line 199:
198 else if (snd_mixer_selem_is_enum_capture(elem)) {
199 int cnt = snd_mixer_selem_get_enum_items(elem);
We (you) discovered that this function returned a negative value. We
also know that snd_mixer_selem_is_enum_capture must be true, otherwise,
we wouldn't enter line 199 at all.
Ok, now let's go back with this knowledge to line 139:
138 else if (snd_mixer_selem_is_enum_capture(elem)) {
139 dev->numselems += snd_mixer_selem_get_enum_items(elem);
and later:
144 dev->selems = calloc(dev->numselems, sizeof(PxSelem));
I wonder what happens if snd_mixer_selem_get_enum_items in line 139
returns a negative value as in line 199. This would make dev->numselems
decrease and finally result in too few memory for dev->selems.
When traversing this memory later, the iterator would finally make an
out of bound access, perhaps causing a segfault.
It could also be the case that some end markers were already
overwritten, perhaps in your loop which increments i to 530.
Possible approaches:
1. Change line 139 to always increment, never decrement
2. Artificially increase the memory pool for dev->selems
3. Add an assertion / check to the for loop comparing i against
dev->numselems.
4. Understand why things are like they are on your system, understand
the code and handle the corner case correctly.
Find attached a "debug patch" that adds some noise to the output and
hopefully gives you an idea where things go wrong.
This is nothing for productive use, but it might move you a little
closer to the culprit. If it starts with this patch, try removing the
constant calloc size multiplier for line 144 and see if it fails again.
You can also play with the constant until you run out of memory. ;)
Things you could try, too: unload the kernel drivers for your various
soundcards, one at a time, until audacity starts.
> (At this point, it would be appropriate if someone could change the
> title of this bug in the BTS, since the complaint about JACK not
> running had nothing to do with the problem. I don't know my way
> around the BTS well enough, yet, to do that -- not even sure if I
> have the permissions to do it.)
[x] done
HTH
--
mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver
Dave Witbrodt
problem, but I have some new information to report.
Since 'audacity' was working for me just a few months ago, I decided I
wanted to try to locate an earlier version that works on my hardware. I
looked at /usr/share/doc/audacity/changelog.Debian.gz, and my best guess
is that I last used version 1.3.10.
(I really wish that I could bisect using 'git'. Does the 'audacity'
upstream use 'git', or do the Debian maintainers have their own 'git'
repo where they merge new versions from upstream? I am merely a
beginner with tools such as 'git' and 'gdb', but I did spend a month
debugging a kernel issue on LKML when kernel 2.6.26 was hanging during
boot on two of my machines, so I believe I could bisect this if the
sources were available via 'git'.)
In the meantime, it occurred to me that Squeeze or Lenny would have an
older version I could try. Squeeze has the same version as Sid, but
Lenny has (the very old) version 1.3.5. I decided that installing Lenny
binaries in Sid would be a bad idea, but downloaded the sources and
tried to build it. The only changes I had to make to allow the build to
succeed were some paths to header files from the 'vamp-plugin-sdk'
build-dependency.
Miracle of miracles! Version 1.3.5 runs fine on my system -- no changes
to my custom /etc/asound.conf file, kernel modules, or anything else
were needed!
I fully intended to dive into the 1.3.12 source code more seriously
tonight, but once I had a working version of 'audacity'... I ended up
just playing with it instead... :-(
Reinhard: I disagree about FFMPEG being a problem in my case. I
provided the warning about my usage of debian-multimedia.org packages of
FFMPEG only for full disclosure. But it is clear that 'audacity' is
crashing during startup on my system because of initialization routines
that are trying to detect the ALSA devices available on my system.
Nothing involving FFMPEG is being touched (so far as I can tell) either
in the code where the crash occurs or in code reached before that point.
I definitely agree that this bug should be taken upstream. However, I
would like to work on understanding the problem for a few days longer,
in the hope I can pin down more exactly why 'audacity' is choking when
trying to grok my system's ALSA devices. Adrian and I have already
discovered some poorly written code, and no doubt there is more such
code in the vicinity which should be challenged upstream. Besides, this
is my big chance to play with 'gdb', about which I know very little!
I've been waiting for an opportunity like this.... ;-)
Adrian: I see that you've looked at the code and have some ideas about
what is going wrong and how to triage and instrument the crash. I
really intended to look seriously at the code tonight, but when 1.3.5
actually worked... I just ended up playing with it, trying to figure out
how to get my guitar pedal to output a stronger signal level so that my
EMU 0404 card's inputs could deliver a decent sound level to 'audacity'.
(I figured it out, BTW, but it wasn't obvious....)
Your suggestions look very interesting, and I hope to try some (or all)
of them out tomorrow night after work. I agree that we are probably
getting more negative return values in nearby code, where it was assumed
there would be no errors. I have some ideas of my own in addition to
yours, but I would like to look more carefully at the code first to try
to get a handle on what it is _supposed_ to be doing. My guess last
night (having barely looked at the code) was that they were trying to
put together a list of capture devices -- something like what 'aplay -l'
or 'aplay -L' would show -- but that they wrote fragile code which works
on most machines but chokes on my EMU 0404 card.
Thanks, and more to come...
Adrian Knoth
> (I really wish that I could bisect using 'git'. Does the 'audacity'
> upstream use 'git', or do the Debian maintainers have their own 'git'
> repo where they merge new versions from upstream? I am merely a
http://packages.qa.debian.org/a/audacity.html
See the VCS link on the left, there it is.
The easy way:
$ debcheckout audacity
This clones you the corresponding git repository.
debcheckout is in the devscripts package.
> beginner with tools such as 'git' and 'gdb', but I did spend a month
Given that you have a memory issue here, I'd like to recommend valgrind.
That's a nice tool to spot out of bound access and the lot.
> Miracle of miracles! Version 1.3.5 runs fine on my system -- no changes
No miracle at all, they changed the code in px_linux_alsa.c. git bisect
will tell you about it.
You might also want to have a look at the upstream svn and read the
commit messages:
http://code.google.com/p/audacity/source/browse/audacity-src/trunk
Good luck. ;)
--
mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver
--
Dave Witbrodt
by tomorrow I hope to either provide draft patches that allow it to run
on my system, or at least provide a more complete description of what's
going wrong with the code.
I see that upstream does not allow people to open their own accounts on
their Bugzilla (like X.org does), so I will need the Debian Multimedia
team to mediate for me.
>> (I really wish that I could bisect using 'git'. Does the 'audacity'
>> upstream use 'git', or do the Debian maintainers have their own 'git'
>> repo where they merge new versions from upstream?
>
> http://packages.qa.debian.org/a/audacity.html
>
> See the VCS link on the left, there it is.
Thanks for pointing this out! I have looked at info on
packages.debian.org before, but never knew about the public VCS links.
Reviewing the 'git' history, I found that the changes that break on my
system were introduced in version 1.3.8.
Reviewing old emails I sent out to people, I see that the last time I
used 'audacity' was mid-March 2009 (!), not any time during 2010. The
date on the emails allowed me to compare with the dates in
changelog.Debian.gz -- and I see now that the Debian version I last used
was 1.3.7-2. The fog is clearing.
>> beginner with tools such as 'git' and 'gdb', but I did spend a month
>
> Given that you have a memory issue here, I'd like to recommend valgrind.
> That's a nice tool to spot out of bound access and the lot.
I haven't tried valgrind yet. The free time during the past week that I
might have used debugging 'audacity' was spent reading about, and
experimenting with, 'gdb'. After reading the 'info' pages, and
practicing with using it on some of my own homemade software, I'm
getting a feel for using it -- stepping through the code, setting break
points and watch points, etc.
So far, it looks like the entire problem is limited to the changes made
to open_mixer() in version 1.3.8 [file=lib-src/portmixer/src/
px_linux_alsa.c]. I won't know if there are problems beyond this
function (or even the file) unless I can get open_mixer() to finish
without segfaulting.
On lines 124-142 (Debian version 1.3.12-3), an attempt is made to count
the number of "selems" (sound elements?) so that dynamic memory can be
reserved (line 144) for a local list of structures holding information
about those elements which is filled up in lines 150-222. In the loop
that counts the selems, the function snd_mixer_selem_get_enum_items()
repeated returns negative error codes for the first half-dozen or dozen
iterations of the "elem" pointer. This causes the value of dev->
numselems to quickly add up into the negative 100's range. Later,
further iterations of "elem" begin to cause dev->numselems to add up to
several hundred (positive). Here is the loop in question, with
problematic line 139 marked with (*):
for (elem = snd_mixer_first_elem(dev->handle);
elem != NULL;
elem = snd_mixer_elem_next(elem))
{
if (playback) {
if (snd_mixer_selem_has_common_volume(elem) ||
snd_mixer_selem_has_playback_volume(elem)) {
dev->numselems++;
}
}
else {
if (snd_mixer_selem_get_capture_group(elem) >= 0) {
dev->numselems++;
}
else if (snd_mixer_selem_is_enum_capture(elem)) {
* dev->numselems += snd_mixer_selem_get_enum_items(elem);
}
}
}
Clearly, the error codes should be ignored and not added to dev->
numselems! The same sort of iteration of "elem" is made later, in the
loop that fills up the array of information structures, and a very
similar error in assuming there would be no error codes returned is made
on line 199 (see Adrian's patch in Message #30 above on the BTS).
I need to take a break for a while, but my next experiment will be to
attempt a workaround in those two loops so that any error code returned
by ALSA on an "elem" pointer will cause the loop to iterate to the next
"elem" (continue).
>> Miracle of miracles! Version 1.3.5 runs fine on my system -- no changes
>
> No miracle at all, they changed the code in px_linux_alsa.c. git bisect
> will tell you about it.
Well, I reported that an earlier version of 'audacity' had been working
for me, so I could not have meant that getting an older version to run
was the miracle.
Instead, I found it miraculous that this very old version of audacity
would compile on this up-to-date Sid system, with much newer versions of
its dependencies than had existed back with 1.3.5 was new! (But, yes, I
probably overreacted ;-)
More to come....
Dave W.