Debian Bug report logs - #584605
audacity: segfault with multiple ALSA devices

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Dave Witbrodt <dawitbro@sbcglobal.net>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: audacity: Segfaults with complaint about jack server not running

Date: Fri, 04 Jun 2010 20:41:59 -0400

Package: audacity
Version: 1.3.12-3
Severity: important
Tags: sid


The last time I used audacity, everything was working fine.  (This was a
few months ago... maybe January.)  There have been several updates in
Sid since then.  Today I wanted to use audacity, but this is what I get:

    $ audacity
    Cannot connect to server socket err = No such file or directory
    Cannot connect to server socket
    jack server is not running or cannot be started
    Segmentation fault

Removing the ~/.audacity-data directory has no effect.

Is JACK now required to be able to use audacity?  In the past, it worked
fine for me just using ALSA.


Thanks,
Dave W.


-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (350, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.34+drt100429.0818fe9.desktop.kms (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages audacity depends on:
ii  audacity-data            1.3.12-3        A fast, cross-platform audio edito
ii  libasound2               1.0.22-2        shared library for ALSA applicatio
ii  libc6                    2.11.1-2        Embedded GNU C Library: Shared lib
ii  libexpat1                2.0.1-7         XML parsing C library - runtime li
ii  libflac++6               1.2.1-2+b1      Free Lossless Audio Codec - C++ ru
ii  libflac8                 1.2.1-2+b1      Free Lossless Audio Codec - runtim
ii  libgcc1                  1:4.4.4-4       GCC support library
ii  libglib2.0-0             2.25.7-1        The GLib library of C routines
ii  libgtk2.0-0              2.21.1-1+xidfix The GTK+ graphical user interface 
ii  libid3tag0               0.15.1b-10      ID3 tag reading library from the M
ii  libjack0                 1.9.5~dfsg-13   JACK Audio Connection Kit (librari
ii  libmad0                  0.15.1b-5       MPEG audio decoder library
ii  libogg0                  1.2.0~dfsg-1    Ogg bitstream library
ii  libsamplerate0           0.1.7-3         Audio sample rate conversion libra
ii  libsndfile1              1.0.21-2        Library for reading/writing audio 
ii  libsoundtouch1c2         1.3.1-2         sound stretching library
ii  libstdc++6               4.4.4-4         The GNU Standard C++ Library v3
ii  libtwolame0              0.3.12-1        MPEG Audio Layer 2 encoding librar
ii  libvamp-hostsdk3         2.1-1           helper library for Vamp hosts writ
ii  libvorbis0a              1.3.1-1         The Vorbis General Audio Compressi
ii  libvorbisenc2            1.3.1-1         The Vorbis General Audio Compressi
ii  libvorbisfile3           1.3.1-1         The Vorbis General Audio Compressi
ii  libwxbase2.8-0           2.8.10.1-3      wxBase library (runtime) - non-GUI
ii  libwxgtk2.8-0            2.8.10.1-3      wxWidgets Cross-platform C++ GUI t

Versions of packages audacity recommends:
ii  libavcodec52       5:0.6~svn20100603-0.0 library to encode decode multimedi
ii  libavformat52      5:0.6~svn20100603-0.0 ffmpeg file format library

Versions of packages audacity suggests:
pn  ladspa-plugin                 <none>     (no description available)
ii  libmp3lame0                   3.98.4-0.0 LAME Ain't an MP3 Encoder

-- no debconf information

Message #10 received at 584605@bugs.debian.org (full text, mbox, reply):

From: Adrian Knoth <adi@drcomp.erfurt.thur.de>

To: Dave Witbrodt <dawitbro@sbcglobal.net>, 584605@bugs.debian.org

Subject: Re: Bug#584605: audacity: Segfaults with complaint about jack server not running

Date: Mon, 7 Jun 2010 19:35:33 +0200

On Fri, Jun 04, 2010 at 08:41:59PM -0400, Dave Witbrodt wrote:

> Package: audacity
> Version: 1.3.12-3

Hmm, works fine over here.

>     $ audacity
>     Cannot connect to server socket err = No such file or directory
>     Cannot connect to server socket
>     jack server is not running or cannot be started
>     Segmentation fault

Do you have a ~/.jackdmp? If so, try to move it away (delete or rename
it).


> Is JACK now required to be able to use audacity?

No.


If it still asks for a jackd for you (don't know why, perhaps via some
kind of .asoundrc, /etc/asound.conf or whatever magic), you could start

   jackd -d dummy

Though this won't give you any output, it should at least enable you to
start audacity. You could then still use the plain ALSA backend.


For a real analysis, we'd need a backtrace:

   http://wiki.debian.org/HowToGetABacktrace



HTH

-- 
mail: adi@thur.de  	http://adi.thur.de	PGP/GPG: key via keyserver

Message #15 received at 584605@bugs.debian.org (full text, mbox, reply):

From: Dave Witbrodt <dawitbro@sbcglobal.net>

To: 584605@bugs.debian.org

Cc: Adrian Knoth <adi@drcomp.erfurt.thur.de>

Subject: Re: Bug#584605: audacity: Segfaults with complaint about jack server not running

Date: Wed, 09 Jun 2010 21:41:27 -0400

>> Package: audacity
>> Version: 1.3.12-3
>
> Hmm, works fine over here.

No doubt.  :)


>>      $ audacity
>>      Cannot connect to server socket err = No such file or directory
>>      Cannot connect to server socket
>>      jack server is not running or cannot be started
>>      Segmentation fault
>
> Do you have a ~/.jackdmp? If so, try to move it away (delete or rename
> it).

No.


> If it still asks for a jackd for you (don't know why, perhaps via some
> kind of .asoundrc, /etc/asound.conf or whatever magic), you could start
>
>     jackd -d dummy
>
> Though this won't give you any output, it should at least enable you to
> start audacity. You could then still use the plain ALSA backend.

Well, I have never had JACK installed, and never had 'audacity' insist 
on its presence before.

I failed to mention before that I do use a heavily customized 
/etc/asound.conf file:  I have a 5.1 surround speaker system, and output 
to it without any sound server (pulse, esound, etc.).  However, this has 
been in place (with no changes) for several years, and 'audacity' worked 
fine with it.  I can provide the contents of that config file upon 
request, but I assure you that there is nothing in it that has anything 
to do with JACK.


> For a real analysis, we'd need a backtrace:
>
>     http://wiki.debian.org/HowToGetABacktrace

I agree.  I've been a bit on the busy side, so I decided to report the 
bug first without running 'gdb'.  I may find some time this weekend.  (I 
also have had a problem -- for over a year -- with 'gmplayer' where it 
crashes when running its configuration dialog, and need to nose around 
with 'gdb' to troubleshoot that.  I just don't use 'mplayer', and have 
had no motivation, and no one else seems to be having the same problem, 
just like this 'audacity' glitch.)

As an added data point, take a quick look at this 'totem' error reported 
on debian-user:

http://lists.debian.org/debian-user/2010/06/msg00591.html

This user is being hit with the same complaint about JACK that I am 
being hit with.  This makes it look like 'audacity' is not the problem 
at all, but some library or other dependency.


Thanks,
Dave W.

Message #20 received at 584605@bugs.debian.org (full text, mbox, reply):

From: Dave Witbrodt <dawitbro@sbcglobal.net>

To: 584605@bugs.debian.org

Cc: Adrian Knoth <adi@drcomp.erfurt.thur.de>

Subject: Re: Bug#584605: audacity: Segfaults with complaint about jack server not running

Date: Wed, 09 Jun 2010 23:12:50 -0400

>>      $ audacity
>>      Cannot connect to server socket err = No such file or directory
>>      Cannot connect to server socket
>>      jack server is not running or cannot be started
>>      Segmentation fault

Seeing this,

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584272

I believe now that the messages about JACK may not be related to the 
crash, and are merely informational (and irrelevant).

Only a backtrace will provide meaningful information, so I will get on 
it ASAP.  Friday or Saturday, hopefully.


Thanks,
Dave W.

Message #25 received at 584605@bugs.debian.org (full text, mbox, reply):

From: Dave Witbrodt <dawitbro@sbcglobal.net>

To: Debian Bug Tracking System <584605@bugs.debian.org>

Subject: audacity: Backtrace, as requested...

Date: Sat, 12 Jun 2010 22:34:22 -0400

Package: audacity
Version: 1.3.12-3
Severity: normal


Sorry for the delay of 5 days on this.  I installed the 'audacity-dbg'
package, and produced the following session with 'gdb':
----------

$ gdb /usr/bin/audacity 
GNU gdb (GDB) 7.1-debian
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/audacity...Reading symbols from /usr/lib/debug/usr/bin/audacity...done.
done.
(gdb) run
Starting program: /usr/bin/audacity 
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffe8d39710 (LWP 314)]
Cannot connect to server socket err = No such file or directory
Cannot connect to server socket
jack server is not running or cannot be started
[Thread 0x7fffe8d39710 (LWP 314) exited]
[New Thread 0x7fffe8ba9710 (LWP 315)]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff37a13d8 in snd_mixer_selem_get_index () from /usr/lib/libasound.so.2
(gdb) bt
#0  0x00007ffff37a13d8 in snd_mixer_selem_get_index () from /usr/lib/libasound.so.2
#1  0x000000000085e917 in open_mixer (dev=0xfd2670, card=<value optimized out>, playback=<value optimized out>) at src/px_linux_alsa.c:214
#2  0x000000000085ec17 in OpenMixer_Linux_ALSA (Px=0xfc6ec0, index=<value optimized out>) at src/px_linux_alsa.c:296
#3  0x000000000085d383 in Px_OpenMixer (pa_stream=0xfc5a90, i=0) at src/px_mixer.c:155
#4  0x000000000051d23f in AudioIO::HandleDeviceChange (this=0xe89c30) at AudioIO.cpp:573
#5  0x000000000051d774 in AudioIO (this=0xe89c30) at AudioIO.cpp:351
#6  0x000000000051d874 in InitAudioIO () at AudioIO.cpp:216
#7  0x0000000000517342 in AudacityApp::OnInit (this=0xddc290) at AudacityApp.cpp:1057
#8  0x00007ffff6d1c632 in wxEntry(int&, wchar_t**) () from /usr/lib/libwx_baseu-2.8.so.0
#9  0x0000000000512f02 in main (argc=1, argv=0x9ea3c3) at AudacityApp.cpp:626
----------

The full backtrace looked like this:
----------

#0  0x00007ffff37a13d8 in snd_mixer_selem_get_index () from /usr/lib/libasound.so.2
No symbol table info available.
#1  0x000000000085e917 in open_mixer (dev=0xfd2670, card=<value optimized out>, playback=<value optimized out>) at src/px_linux_alsa.c:214
        iname = '\000' <repeats 24 times>, "0\000\000\000\000\000\000\000\230~\264\362\377\177\000\000\250~\264\362\377\177\000\000\000\000\000\000\000\000\000\000 \000\000\000\000\000\000\000\263\016\000\000\003\000\000\000P~\264\362\377\177\000\000P\000\000\000\000\000\000\000\030\335\377\377\003\000\000\000 \335\377\377\377\177\000\000\000[\374\000\000\000\000\000@~\264\362\377\177\000\000 ", '\000' <repeats 15 times>, "\001", '\000' <repeats 15 times>, "p\031\206\362\377\177\000\000\000\200\000\000\000\000\000\000\000[\374\000\000\000\000\000\260\016\000\000\000\000\000\000\260\016", '\000' <repeats 14 times>, "9ȅ", '\000' <repeats 17 times>"\200, \210\345@\003\000\000\000\000\000\000\000\220Z\374\000\000\000\000\000\000[\374\000\000\000\000\000\220\335\377\377\377\177\000"
        cnt = 4294967274
        j = 826
        vol = 0x0
        err = <value optimized out>
        i = <value optimized out>
        elem = 0xf867a0
        name = ":0\000\060\000\000\000\000\200j\350\000\000\000\000\000\003\000\000\000\000\000\000\000\202\003\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>"\200, \336\377\377\377\177\000\000\220]\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\000\230~\264\362\377\177\000\000\250~\264\362\377\177\000\000H\263g\256\031Τ?P\000\000\000\000\000\000\000\240\335\377\377\006\000\000\000h~\264\362\377\177\000\000\200\000\000\000\000\000\000\000\360\000\000\000\006\000\000\000\230~\264\362\377\177\000\000\300n\374\000\000\000\000\000Pz\002\000\000\000\000\000\260\265\375\000\000\000\000\000P\000\000\000\000\000\000\000*\254\204\000\000\000\000"
#2  0x000000000085ec17 in OpenMixer_Linux_ALSA (Px=0xfc6ec0, index=<value optimized out>) at src/px_linux_alsa.c:296
        card = 0
#3  0x000000000085d383 in Px_OpenMixer (pa_stream=0xfc5a90, i=0) at src/px_mixer.c:155
        good = <value optimized out>
#4  0x000000000051d23f in AudioIO::HandleDeviceChange (this=0xe89c30) at AudioIO.cpp:573
        recDeviceNum = <value optimized out>
        stream = 0xfc5a90
        playDeviceNum = <value optimized out>
        numrates = <value optimized out>
        highestSampleRate = <value optimized out>
        error = 16541152
        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
#5  0x000000000051d774 in AudioIO (this=0xe89c30) at AudioIO.cpp:351
        err = <value optimized out>
#6  0x000000000051d874 in InitAudioIO () at AudioIO.cpp:216
No locals.
#7  0x0000000000517342 in AudacityApp::OnInit (this=0xddc290) at AudacityApp.cpp:1057
        future1 = {<wxStringBase> = {static npos = 18446744073709551615, m_pchData = 0xdea9e8 L"Master Gain Control"}, <No data fields>}
        lang = {<wxStringBase> = {static npos = 18446744073709551615, m_pchData = 0xe88748 L"en"}, <No data fields>}
        pWnd = <value optimized out>
        appName = {<wxStringBase> = {static npos = 18446744073709551615, m_pchData = 0xdea908 L"audacity"}, <No data fields>}
        future2 = {<wxStringBase> = {static npos = 18446744073709551615, m_pchData = 0xddc718 L"Input Meter"}, <No data fields>}
        home = {<wxStringBase> = {static npos = 18446744073709551615, m_pchData = 0xdec0e8 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 = 0xe831c0, 
            m_autoSort = false}, m_name = {<wxStringBase> = {static npos = 18446744073709551615, m_pchData = 0xe82ad8 L"nnI9gJuj"}, <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 = 0xdea978 L"audacity"}, <No data fields>}
        future3 = {<wxStringBase> = {static npos = 18446744073709551615, m_pchData = 0xdeaa98 L"Output Meter"}, <No data fields>}
        tmpDirLoc = {<wxStringBase> = {static npos = 18446744073709551615, m_pchData = 0xe82bd8 L"/tmp"}, <No data fields>}
        didRecoverAnything = <value optimized out>
#8  0x00007ffff6d1c632 in wxEntry(int&, wchar_t**) () from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#9  0x0000000000512f02 in main (argc=1, argv=0x9ea3c3) at AudacityApp.cpp:626
No locals.
----------


Looking at the values of "j" (826) and "cnt" (4294967274) at the time of the crash,
they look out of the ballpark to me.  This is the loop being iterated (in
lib-src/portmixer/src/px_linux_alsa.c) which hits those values:

         else if (snd_mixer_selem_is_enum_capture(elem)) {
            unsigned int cnt = snd_mixer_selem_get_enum_items(elem);
            unsigned int j;

            for (j = 0; j < cnt; j++) {
               char iname[256];
               snd_mixer_selem_get_enum_item_name(elem, j, sizeof(iname), iname);
               snprintf(name,
                        sizeof(name),
                        "%s:%d",
                        iname,
                        snd_mixer_selem_get_index(elem));

               dev->selems[i].vol = vol;
               dev->selems[i].item = j;
               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++;
            }

The huge value for "cnt" suggests that snd_mixer_selem_get_enum_items() is
returning a negative number here, but upstream has coded this function to store
the return value in an unsigned int (and not bother to check it!).

Looking for some documentation, I found:

    http://www.alsa-project.org/alsa-doc/alsa-lib/group___simple_mixer.html#g23600e756612dca7ea8329994590fa19

	int  snd_mixer_selem_get_enum_items  (snd_mixer_elem_t  *elem)	

            Return the number of enumerated items of the given mixer simple element.

	Parameters:
	    elem    Mixer simple element handle

	Returns:
	    the number of enumerated items, otherwise a negative error code 

Oops!  This thing can return negative numbers, but upstream thought it wouldn't
happen.


What I would really like (from upstream? from a Debian patch?) is for 'audacity'
to be able to run long enough for me to be able to configure it properly.  On my
system, ALSA picks up 3 different sound devices when the kernel boots, and the
proper "card" to use for output is not the default card #0:

    $ dmesg | grep -i -A 3 alsa
    ALSA device list:
      #0: E-mu 0404b PCI [MAEM8852] (rev.0, serial:0x40021102) at 0xe800, irq 23
      #1: HDA ATI SB at 0xfe7f0000 irq 16
      #2: HDA ATI HDMI at 0xfe8ec000 irq 32

The first device is an inexpensive DSP card I use to plug in guitars; the second
is the sound chipset on my motherboard (which would otherwise have been the
default) and which I would like to use for sound output (/etc/asound.conf is
configured for that purpose); and the third device the the HDMI outputs on my
video card.

As I mentioned when opening this bug report:  the last time I used 'audacity'
it worked fine.  That was probably in January, unfortunately, and there have
probably been several upgrades in versions of 'audacity' since then.  I cannot
say which upgrade version first showed this regression; I cannot even say
which was the last working version!  Sorry about that.


If I can provide more information, test any patches, or be of help in some
other way just let me know.


Thanks,
Dave W.

PS:  Sid changes frequently, and I upgraded from ALSA 1.0.22 to 1.0.23 (no
change in 'audacity' regression behavior) to allow some other software to be
brought in, so I am allowing 'reportbug' to list the full set of system
information again.  It's probably irrelevant, so sorry for the spam, but
Just In Case....


-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (350, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.34+drt100429.0818fe9.desktop.kms (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages audacity depends on:
ii  audacity-data            1.3.12-3        A fast, cross-platform audio edito
ii  libasound2               1.0.23-1        shared library for ALSA applicatio
ii  libc6                    2.11.1-3        Embedded GNU C Library: Shared lib
ii  libexpat1                2.0.1-7         XML parsing C library - runtime li
ii  libflac++6               1.2.1-2+b1      Free Lossless Audio Codec - C++ ru
ii  libflac8                 1.2.1-2+b1      Free Lossless Audio Codec - runtim
ii  libgcc1                  1:4.4.4-5       GCC support library
ii  libglib2.0-0             2.25.8-1        The GLib library of C routines
ii  libgtk2.0-0              2.21.2-1+xidfix The GTK+ graphical user interface 
ii  libid3tag0               0.15.1b-10      ID3 tag reading library from the M
ii  libjack0                 1.9.5~dfsg-13   JACK Audio Connection Kit (librari
ii  libmad0                  0.15.1b-5       MPEG audio decoder library
ii  libogg0                  1.2.0~dfsg-1    Ogg bitstream library
ii  libsamplerate0           0.1.7-3         Audio sample rate conversion libra
ii  libsndfile1              1.0.21-2        Library for reading/writing audio 
ii  libsoundtouch1c2         1.3.1-2         sound stretching library
ii  libstdc++6               4.4.4-5         The GNU Standard C++ Library v3
ii  libtwolame0              0.3.12-1        MPEG Audio Layer 2 encoding librar
ii  libvamp-hostsdk3         2.1-1           helper library for Vamp hosts writ
ii  libvorbis0a              1.3.1-1         The Vorbis General Audio Compressi
ii  libvorbisenc2            1.3.1-1         The Vorbis General Audio Compressi
ii  libvorbisfile3           1.3.1-1         The Vorbis General Audio Compressi
ii  libwxbase2.8-0           2.8.10.1-3      wxBase library (runtime) - non-GUI
ii  libwxgtk2.8-0            2.8.10.1-3      wxWidgets Cross-platform C++ GUI t

Versions of packages audacity recommends:
ii  libavcodec52       5:0.6~svn20100603-0.0 library to encode decode multimedi
ii  libavformat52      5:0.6~svn20100603-0.0 ffmpeg file format library

Versions of packages audacity suggests:
pn  ladspa-plugin                 <none>     (no description available)
ii  libmp3lame0                   3.98.4-0.0 LAME Ain't an MP3 Encoder

-- no debconf information

Message #30 received at 584605@bugs.debian.org (full text, mbox, reply):

From: Adrian Knoth <adi@drcomp.erfurt.thur.de>

To: Dave Witbrodt <dawitbro@sbcglobal.net>, 584605@bugs.debian.org

Subject: Re: Bug#584605: audacity: Backtrace, as requested...

Date: Sun, 13 Jun 2010 12:46:04 +0200

[Message part 1 (text/plain, inline)]

On Sat, Jun 12, 2010 at 10:34:22PM -0400, Dave Witbrodt wrote:

> Looking at the values of "j" (826) and "cnt" (4294967274) at the time
> of the crash, they look out of the ballpark to me.  This is the loop
> being iterated (in lib-src/portmixer/src/px_linux_alsa.c) which hits
> those values:

> 
>          else if (snd_mixer_selem_is_enum_capture(elem)) {
>             unsigned int cnt = snd_mixer_selem_get_enum_items(elem);
>             unsigned int j;
> 
>             for (j = 0; j < cnt; j++) {
>                char iname[256];
>                snd_mixer_selem_get_enum_item_name(elem, j, sizeof(iname), iname);
(..)
>                   break;
>                }
>                i++;
>             }
> 
> The huge value for "cnt" suggests that
> snd_mixer_selem_get_enum_items() is returning a negative number here,
> but upstream has coded this function to store the return value in an
> unsigned int (and not bother to check it!).

Exactly.

> Looking for some documentation, I found:
> 
>     http://www.alsa-project.org/alsa-doc/alsa-lib/group___simple_mixer.html#g23600e756612dca7ea8329994590fa19
> 
> 	int  snd_mixer_selem_get_enum_items  (snd_mixer_elem_t  *elem)	

> 	Returns:
> 	    the number of enumerated items, otherwise a negative error code 
> 
> Oops!  This thing can return negative numbers, but upstream thought it
> wouldn't happen.

Thank you so much. Best bug report I've ever seen. Really. ;)

> If I can provide more information, test any patches, or be of help in some
> other way just let me know.

Find attached a quick fix. Untested, but it basically does what you've
suggested: don't run the loop when cnt is negative.

Does it fix the problem?


TIA

-- 
mail: adi@thur.de  	http://adi.thur.de	PGP/GPG: key via keyserver

[audacity-crash.patch (text/x-diff, attachment)]

Message #35 received at 584605@bugs.debian.org (full text, mbox, reply):

From: Dave Witbrodt <dawitbro@sbcglobal.net>

To: Adrian Knoth <adi@drcomp.erfurt.thur.de>

Cc: 584605@bugs.debian.org

Subject: Re: Bug#584605: audacity: Backtrace, as requested...

Date: Sun, 13 Jun 2010 18:07:42 -0400

On 06/13/2010 06:46 AM, Adrian Knoth wrote:
> Thank you so much. Best bug report I've ever seen. Really. ;)

Thank you very much!

In my free time, I am learning how to contribute to Debian more 
seriously.  I hope to someday become a DM, or even a DD, but before that 
need to increase my skill level with packaging, coding, and debugging. 
At this point, the plan is to become the Batman of the Debian BTS for a 
year or two -- swooping down on bugs and fixing them before the DM's and 
DD's have to -- before I apply for new maintainer status.

My latest results are (for me) humbling, making clear that I am nowhere 
near Batman status.  I have compiled some more results, but it has just 
occurred to me that we'll get horrible line-wrapping if I try to provide 
them with this Icedove email client....

> Find attached a quick fix. Untested, but it basically does what you've
> suggested: don't run the loop when cnt is negative.
>
> Does it fix the problem?

Maybe.  That specific problem has gone away.

Now when I run 'audacity' I hear a click, like it is trying to start up, 
but it is segfaulting in another place and the window still never even 
appears.  Let me bail out of Icedove, and respond more fully via 
reportbug/emacs.


Thanks,
DW

Message #40 received at 584605@bugs.debian.org (full text, mbox, reply):

From: Dave Witbrodt <dawitbro@sbcglobal.net>

To: Debian Bug Tracking System <584605@bugs.debian.org>

Subject: audacity: Continuing to backtrace

Date: Sun, 13 Jun 2010 18:11:08 -0400

Package: audacity
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.

Message #45 received at 584605@bugs.debian.org (full text, mbox, reply):

From: Reinhard Tartler <siretart@tauware.de>

To: Dave Witbrodt <dawitbro@sbcglobal.net>

Cc: 584605@bugs.debian.org

Subject: Re: Bug#584605: audacity: Continuing to backtrace

Date: Mon, 14 Jun 2010 07:18:24 +0200

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

Message #52 received at 584605@bugs.debian.org (full text, mbox, reply):

From: Adrian Knoth <adi@drcomp.erfurt.thur.de>

To: Dave Witbrodt <dawitbro@sbcglobal.net>, 584605@bugs.debian.org

Subject: Re: Bug#584605: audacity: Continuing to backtrace

Date: Mon, 14 Jun 2010 22:34:26 +0200

[Message part 1 (text/plain, inline)]

On Sun, Jun 13, 2010 at 06:11:08PM -0400, Dave Witbrodt wrote:

> *        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: adi@thur.de  	http://adi.thur.de	PGP/GPG: key via keyserver

[audacity-debug.patch (text/x-diff, attachment)]

Message #57 received at 584605@bugs.debian.org (full text, mbox, reply):

From: Dave Witbrodt <dawitbro@sbcglobal.net>

To: 584605@bugs.debian.org

Cc: Adrian Knoth <adi@drcomp.erfurt.thur.de>, Reinhard Tartler <siretart@tauware.de>

Subject: Re: Bug#584605: audacity: Continuing to backtrace

Date: Tue, 15 Jun 2010 02:30:52 -0400

I didn't accomplish very much after work tonight toward debugging this 
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...
Dave W.

Message #62 received at 584605@bugs.debian.org (full text, mbox, reply):

From: Adrian Knoth <adi@drcomp.erfurt.thur.de>

To: Dave Witbrodt <dawitbro@sbcglobal.net>

Cc: 584605@bugs.debian.org

Subject: Re: Bug#584605: audacity: Continuing to backtrace

Date: Tue, 15 Jun 2010 08:43:05 +0200

On Tue, Jun 15, 2010 at 02:30:52AM -0400, Dave Witbrodt wrote:

> (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: adi@thur.de  	http://adi.thur.de	PGP/GPG: key via keyserver

Message #67 received at 584605@bugs.debian.org (full text, mbox, reply):

From: Dave Witbrodt <dawitbro@sbcglobal.net>

To: 584605@bugs.debian.org

Cc: Adrian Knoth <adi@drcomp.erfurt.thur.de>

Subject: Re: Bug#584605: audacity: Continuing to backtrace

Date: Sat, 26 Jun 2010 18:56:38 -0400

I haven't had much time to work on this 'audacity' bug until today, but 
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.

Message #72 received at 584605@bugs.debian.org (full text, mbox, reply):

From: Dave Witbrodt <dawitbro@sbcglobal.net>

To: Debian Bug Tracking System <584605@bugs.debian.org>

Subject: Patch attached allows audacity to run on my system

Date: Sun, 27 Jun 2010 00:26:10 -0400

[Message part 1 (text/plain, inline)]

Package: audacity
Version: 1.3.12-3+fix04
Severity: normal


(Please ignore the "Version" string above -- it's just my local build.)

The patch attached, small as it is, seems to give me a fully-functional
'audacity' with my troublesome hardware.  At the very least, I think we
have learned that success calling snd_mixer_selem_is_enum_capture() does
not guarantee snd_mixer_selem_get_enum_items() will not fail, and
upstream needs to check return values from library functions before
using those values.

This will be my last unprompted message to this bug report, but if more
information is desired -- either from the Debian team, or from upstream
-- just let me know.  I have run 'reportbug' with options to attach two
files:  the first is the patch that fixes audacity; the second is a 48kB
OGG file with proof that I can capture input from my bass using the EMU
card's inputs and process it with 'audacity'.  (Yessssss!)  If anything
goes wrong with the attachments, I'll try following up using another
method.  (For reference, the patch applies against Debian version
1.3.12-3.)

Since the 'audacity' upstream does not allow individuals to create their
own Bugzilla accounts, and I doubt that I'll be touching much 'audacity'
code in the near future, I was hoping that one of you on the Debian team
could use your own connections with upstream to pass along what I have
learned.  Point them at this bug report, and make it clear that they can
contact me directly if they want to know more about my hardware or my
experience with this bug.


Now that I've looked at some ALSA-related code, I consider this an
opportunity to look into alsalib more.  I want to find out exactly why
audacity 1.3.7 works and 1.3.12 fails.  I'll begin by copying parts of
the code from open_mixer(), where it enumerates the sound elements
discovered by alsalib, but simply have it print what it discovers
instead of saving the info to an array.  But none of that has anything
to do with this bug report....


Thanks, and HTH,
Dave W.

[04-open_mixer-workaround.patch (text/x-c, attachment)]

[success.ogg (application/ogg, attachment)]

Message #77 received at 584605@bugs.debian.org (full text, mbox, reply):

From: Dave Witbrodt <dawitbro@sbcglobal.net>

To: Debian Bug Tracking System <584605@bugs.debian.org>

Date: Sun, 27 Jun 2010 22:24:11 -0400

[Message part 1 (text/plain, inline)]

When 'audacity' first loads, it tries to grab information about capture
and playback elements for card number 0.  On my system, ALSA finds my
cheap DSP card first, so it becomes card 0:

    $ aplay -l | grep card
    card 0: EMU0404 [E-mu 0404b PCI [MAEM8852]], device 0: emu10k1 [ADC Capture/Standard PCM Playback]
    card 0: EMU0404 [E-mu 0404b PCI [MAEM8852]], device 2: emu10k1 efx [Multichannel Capture/PT Playback]
    card 0: EMU0404 [E-mu 0404b PCI [MAEM8852]], device 3: emu10k1 [Multichannel Playback]
    card 1: SB [HDA ATI SB], device 0: ALC889 Analog [ALC889 Analog]
    card 1: SB [HDA ATI SB], device 1: ALC889 Digital [ALC889 Digital]
    card 2: HDMI [HDA ATI HDMI], device 3: ATI HDMI [ATI HDMI]

The changes from 'audacity' version 1.3.7 to 1.3.8 left portmixer's
open_mixer() function unable to handle the capture elements on that card
-- it's not hard to understand why:

    $ amixer -D hw:0 scontrols
    Simple mixer control 'Master',0
    Simple mixer control 'Tone',0
    Simple mixer control 'Bass',0
    Simple mixer control 'Treble',0
    Simple mixer control 'PCM',0
    Simple mixer control 'PCM Center',0
    Simple mixer control 'PCM Front',0
    Simple mixer control 'PCM LFE',0
    Simple mixer control 'PCM Side',0
    Simple mixer control 'PCM Surround',0
    Simple mixer control 'Front',0
    Simple mixer control 'Surround',0
    Simple mixer control 'Center',0
    Simple mixer control 'LFE',0
    Simple mixer control 'Side',0
    Simple mixer control 'Synth',0
    Simple mixer control 'DSP 0',0
    Simple mixer control 'DSP 1',0
    Simple mixer control 'DSP 10',0
    Simple mixer control 'DSP 11',0
    Simple mixer control 'DSP 12',0
    Simple mixer control 'DSP 13',0
    Simple mixer control 'DSP 14',0
    Simple mixer control 'DSP 15',0
    Simple mixer control 'DSP 2',0
    Simple mixer control 'DSP 3',0
    Simple mixer control 'DSP 4',0
    Simple mixer control 'DSP 5',0
    Simple mixer control 'DSP 6',0
    Simple mixer control 'DSP 7',0
    Simple mixer control 'DSP 8',0
    Simple mixer control 'DSP 9',0
    Simple mixer control 'DSP A',0
    Simple mixer control 'DSP B',0
    Simple mixer control 'DSP C',0
    Simple mixer control 'DSP D',0
    Simple mixer control 'DSP E',0
    Simple mixer control 'DSP F',0
    Simple mixer control 'Line',0
    Simple mixer control 'CD',0
    Simple mixer control 'Mic',0
    Simple mixer control 'IEC958 Optical',0
    Simple mixer control 'IEC958 Optical Raw',0
    Simple mixer control 'Aux',0
    Simple mixer control '0202 DAC Left',0
    Simple mixer control '0202 DAC Right',0
    Simple mixer control '1010 ADAT 0',0
    Simple mixer control '1010 ADAT 1',0
    Simple mixer control '1010 ADAT 2',0
    Simple mixer control '1010 ADAT 3',0
    Simple mixer control '1010 ADAT 4',0
    Simple mixer control '1010 ADAT 5',0
    Simple mixer control '1010 ADAT 6',0
    Simple mixer control '1010 ADAT 7',0
    Simple mixer control '1010 SPDIF Left',0
    Simple mixer control '1010 SPDIF Right',0
    Simple mixer control 'ADC1 14dB PAD 0202',0
    Simple mixer control 'ADC1 14dB PAD Audio Dock',0
    Simple mixer control 'ADC2 14dB PAD Audio Dock',0
    Simple mixer control 'ADC3 14dB PAD Audio Dock',0
    Simple mixer control 'Analog Mix',0
    Simple mixer control 'Clock Internal Rate',0
    Simple mixer control 'DAC1 0202 14dB PAD',0
    Simple mixer control 'DAC1 Audio Dock 14dB PAD',0
    Simple mixer control 'DAC2 Audio Dock 14dB PAD',0
    Simple mixer control 'DAC3 Audio Dock 14dB PAD',0
    Simple mixer control 'DAC4 Audio Dock 14dB PAD',0
    Simple mixer control 'Dock DAC1 Left',0
    Simple mixer control 'Dock DAC1 Right',0
    Simple mixer control 'Dock DAC2 Left',0
    Simple mixer control 'Dock DAC2 Right',0
    Simple mixer control 'Dock DAC3 Left',0
    Simple mixer control 'Dock DAC3 Right',0
    Simple mixer control 'Dock DAC4 Left',0
    Simple mixer control 'Dock DAC4 Right',0
    Simple mixer control 'Dock Phones Left',0
    Simple mixer control 'Dock Phones Right',0
    Simple mixer control 'Dock SPDIF Left',0
    Simple mixer control 'Dock SPDIF Right',0
    Simple mixer control 'EMU',0

The output from the attached test program tells the story:

	    Creating mixer, returning handle...
	    Attaching mixer to hw:0...
	    Registering mixer...
	    Loading mixer elements...
	    Looping through capture elements...
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems -22 ==> 0)...
    "Master"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems -44 ==> 0)...
    "Tone"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems -66 ==> 0)...
    "Bass"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems -88 ==> 0)...
    "Treble"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems -110 ==> 0)...
    "PCM"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems -132 ==> 0)...
    "PCM Center"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems -154 ==> 0)...
    "PCM Front"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems -176 ==> 0)...
    "PCM LFE"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems -198 ==> 0)...
    "PCM Side"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems -220 ==> 0)...
    "PCM Surround"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems -242 ==> 0)...
    "Front"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems -264 ==> 0)...
    "Surround"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems -286 ==> 0)...
    "Center"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems -308 ==> 0)...
    "LFE"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems -330 ==> 0)...
    "Side"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems -352 ==> 0)...
    "Synth"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned 53  (numselems -299 ==> 53)...
    "DSP 0"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned 53  (numselems -246 ==> 106)...
    "DSP 1"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned 53  (numselems -193 ==> 159)...
    "DSP 10"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned 53  (numselems -140 ==> 212)...
    "DSP 11"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned 53  (numselems -87 ==> 265)...
    "DSP 12"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned 53  (numselems -34 ==> 318)...
    "DSP 13"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned 53  (numselems 19 ==> 371)...
    "DSP 14"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned 53  (numselems 72 ==> 424)...
    "DSP 15"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned 53  (numselems 125 ==> 477)...
    "DSP 2"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned 53  (numselems 178 ==> 530)...
    "DSP 3"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned 53  (numselems 231 ==> 583)...
    "DSP 4"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned 53  (numselems 284 ==> 636)...
    "DSP 5"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned 53  (numselems 337 ==> 689)...
    "DSP 6"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned 53  (numselems 390 ==> 742)...
    "DSP 7"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned 53  (numselems 443 ==> 795)...
    "DSP 8"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned 53  (numselems 496 ==> 848)...
    "DSP 9"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned 53  (numselems 549 ==> 901)...
    "DSP A"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned 53  (numselems 602 ==> 954)...
    "DSP B"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned 53  (numselems 655 ==> 1007)...
    "DSP C"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned 53  (numselems 708 ==> 1060)...
    "DSP D"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned 53  (numselems 761 ==> 1113)...
    "DSP E"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned 53  (numselems 814 ==> 1166)...
    "DSP F"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems 792 ==> 1166)...
    "Line"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems 770 ==> 1166)...
    "CD"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems 748 ==> 1166)...
    "Mic"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems 726 ==> 1166)...
    "IEC958 Optical"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems 704 ==> 1166)...
    "IEC958 Optical Raw"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems 682 ==> 1166)...
    "Aux"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems 660 ==> 1166)...
    "ADC1 14dB PAD 0202"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems 638 ==> 1166)...
    "ADC1 14dB PAD Audio Dock"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems 616 ==> 1166)...
    "ADC2 14dB PAD Audio Dock"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems 594 ==> 1166)...
    "ADC3 14dB PAD Audio Dock"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems 572 ==> 1166)...
    "Analog Mix"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems 550 ==> 1166)...
    "DAC1 0202 14dB PAD"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems 528 ==> 1166)...
    "DAC1 Audio Dock 14dB PAD"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems 506 ==> 1166)...
    "DAC2 Audio Dock 14dB PAD"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems 484 ==> 1166)...
    "DAC3 Audio Dock 14dB PAD"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems 462 ==> 1166)...
    "DAC4 Audio Dock 14dB PAD"  (index = 0)
    Found capture element: snd_mixer_selem_get_enum_items() returned -22  (numselems 440 ==> 1166)...
    "EMU"  (index = 0)
	    Closing handle to mixer...
	    Successful termination!

I was just tinkering around with this for fun (I'll quit now), but I
thought this might illustrate to upstream what was happening at my end.


Thanks again,
Dave W.

[ade-1.0.c (text/x-c, attachment)]

Message #82 received at 584605@bugs.debian.org (full text, mbox, reply):

From: Adrian Knoth <adi@drcomp.erfurt.thur.de>

To: Dave Witbrodt <dawitbro@sbcglobal.net>, 584605@bugs.debian.org

Subject: Re: Bug#584605: Patch attached allows audacity to run on my system

Date: Tue, 29 Jun 2010 14:36:50 +0200

On Sun, Jun 27, 2010 at 12:26:10AM -0400, Dave Witbrodt wrote:

> Since the 'audacity' upstream does not allow individuals to create their
> own Bugzilla accounts, and I doubt that I'll be touching much 'audacity'
> code in the near future, I was hoping that one of you on the Debian team
> could use your own connections with upstream to pass along what I have
> learned.  Point them at this bug report, and make it clear that they can

I just forwarded your patch to audacity-devel with a link to our BTS.


Thanks for all your work, it was a pleasure to hunt this bug. ;)


Let's hope it gets included in the next release (should I add it to the
Debian package until then?).


Cheerio

-- 
mail: adi@thur.de  	http://adi.thur.de	PGP/GPG: key via keyserver

Message #87 received at 584605@bugs.debian.org (full text, mbox, reply):

From: Dave Witbrodt <dawitbro@sbcglobal.net>

To: 584605@bugs.debian.org

Cc: Adrian Knoth <adi@drcomp.erfurt.thur.de>

Subject: Re: Bug#584605: Patch attached allows audacity to run on my system

Date: Tue, 29 Jun 2010 09:24:11 -0400

> I just forwarded your patch to audacity-devel with a link to our BTS.
>
> Thanks for all your work, it was a pleasure to hunt this bug. ;)

Hmmm, when I looked at the upstream website and noticed they had a 
Bugzilla, I assumed that would be the most appropriate way to share my 
info.  I didn't even bother to notice their mailing lists!  (Very 
embarassing....  I could easily have subscribed -- temporarily -- and 
let them know about all of this myself.)

At any rate, thanks for forwarding the info.


> Let's hope it gets included in the next release (should I add it to the
> Debian package until then?).

On the question of having a temporary Debian patch...  this is judgment 
call, so let's consider some facts:

1)  So far, I'm the only one reporting a segfault on startup having to 
do with the 1.3.7 -> 1.3.8 open_mixer() changes

2)  I have the patch I need to make 1.3.8+ work on my hardware

In your place, my approach would be to wait to see how upstream responds 
instead of immediately producing a patched Debian package.  If upstream 
seems to be taking a long time without incorporating the change, and if 
even _one_ more bug report about the same issue hits the Debian BTS 
(which I doubt will happen), then I would release a patched package.

Naturally, I don't know (yet) about the Debian policies, practices, and 
standard operating procedures that govern decisions like this... if 
there are any.  If you are asking whether I would like to see official 
DEBs... just for me... then I say, "No need!":

  $ apt-cache policy audacity
  audacity:
    Installed: 1.3.12-3+fix04
    Candidate: 1.3.12-3+fix04
    Version table:
   *** 1.3.12-3+fix04 0
          100 /var/lib/dpkg/status
       1.3.12-3 0
          990 http://debian.osuosl.org unstable/main Packages


Thanks (to the whole team) for all of your work,
and especially to Adrian for all of the helpful interaction,
Dave W.

Message #92 received at 584605-close@bugs.debian.org (full text, mbox, reply):

From: Benjamin Drung <bdrung@ubuntu.com>

To: 584605-close@bugs.debian.org

Subject: Bug#584605: fixed in audacity 1.3.12-4

Date: Wed, 30 Jun 2010 00:02:28 +0000

Source: audacity
Source-Version: 1.3.12-4

We believe that the bug you reported is fixed in the latest version of
audacity, which is due to be installed in the Debian FTP archive:

audacity-data_1.3.12-4_all.deb
  to main/a/audacity/audacity-data_1.3.12-4_all.deb
audacity-dbg_1.3.12-4_amd64.deb
  to main/a/audacity/audacity-dbg_1.3.12-4_amd64.deb
audacity_1.3.12-4.debian.tar.bz2
  to main/a/audacity/audacity_1.3.12-4.debian.tar.bz2
audacity_1.3.12-4.dsc
  to main/a/audacity/audacity_1.3.12-4.dsc
audacity_1.3.12-4_amd64.deb
  to main/a/audacity/audacity_1.3.12-4_amd64.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 584605@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Benjamin Drung <bdrung@ubuntu.com> (supplier of updated audacity package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Wed, 30 Jun 2010 01:09:55 +0200
Source: audacity
Binary: audacity audacity-data audacity-dbg
Architecture: source amd64 all
Version: 1.3.12-4
Distribution: unstable
Urgency: low
Maintainer: Debian Multimedia Maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>
Changed-By: Benjamin Drung <bdrung@ubuntu.com>
Description: 
 audacity   - A fast, cross-platform audio editor
 audacity-data - A fast, cross-platform audio editor (data)
 audacity-dbg - A fast, cross-platform audio editor (debug)
Closes: 584605
Changes: 
 audacity (1.3.12-4) unstable; urgency=low
 .
   [ Fabian Greffrath ]
   * Fix debian/watch to consult sourceforge again, as googlecode changed
     their download page link format.
   * Update my e-mail address.
 .
   [ Benjamin Drung ]
   * Switch from CDBS to dh 7.
   * Convert versioned Conflicts into Breaks.
   * Simplify debian/rules.
   * Bump Standards-Version to 3.9.0 (no changes required).
   * Add open-mixer.patch to fix segfault with multiple ALSA devices.
     (Closes: #584605) - thanks to Dave Witbrodt <dawitbro@sbcglobal.net>
Checksums-Sha1: 
 533f96cf63ff93595ddc46f5c9a66a25f17d5323 2600 audacity_1.3.12-4.dsc
 aa8f9e05abaa3254606e8dcd265bba1fc876011e 15107 audacity_1.3.12-4.debian.tar.bz2
 9e762167ba23267ee2fddc4226b95333ec346558 2761918 audacity_1.3.12-4_amd64.deb
 33ed6b44d09117de7da2ef1bfe64265e924a9774 2338696 audacity-data_1.3.12-4_all.deb
 dfeeb35f73a3b01795b42a05f2189cf84aa3a9e8 14508 audacity-dbg_1.3.12-4_amd64.deb
Checksums-Sha256: 
 cadd8531cc391005e4325b58d78a929cc761c12e95dea5d9da3ac7991872f6b1 2600 audacity_1.3.12-4.dsc
 a9aa91e59dc2152a291170b96b86389f89fcbe733dd7526493d04da51dd07167 15107 audacity_1.3.12-4.debian.tar.bz2
 17a8cd9c487d9c8d16844c28ced3a521b0cb72462f3b86fdf645a4e58daf347c 2761918 audacity_1.3.12-4_amd64.deb
 b1e700ee0f579814a675079a4e7d21331148709f7e7427a62572c65981c13e4c 2338696 audacity-data_1.3.12-4_all.deb
 cd077c4af3742abeab9072b1a684885df28e89ff17e31515f84f8482e31b8f08 14508 audacity-dbg_1.3.12-4_amd64.deb
Files: 
 0d1413f41e7d5cfd05fbd5c2084a28ac 2600 sound optional audacity_1.3.12-4.dsc
 e0044c623c62a4a07e7b754cfba24cdf 15107 sound optional audacity_1.3.12-4.debian.tar.bz2
 e0fb8b37af55f69c991dd62ae64b0113 2761918 sound optional audacity_1.3.12-4_amd64.deb
 74fd9703cd4c050ac781b3037ef26aa7 2338696 sound optional audacity-data_1.3.12-4_all.deb
 c55c3d621499557a2d0fdce8710249fe 14508 debug extra audacity-dbg_1.3.12-4_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCgAGBQJMKoUqAAoJEBWetcTvyHdMI8EQAJscOanbEQCrhFAA+MpfwZcP
ZKYRrmUkqpyqgPml+WUbsWXZYGxGt5oarMhzO/3KjSao69f8B5NzzjTY6JIy9Af5
meknv9SDmCpBRKh4F0MkQyvzNtvkspFVtRWF+gYS6odY9rURWWJc9sJp3+d4HlQs
ujMbaj5H5l3OTh65IxDJ4dTuc49ryOMrqFBGTKJI0RZpW4v4bBuUcgO0pwbGxAsJ
MyAZPXKa8Ks/nEPWh5IaHtjLNVFEmUbelPkPX4J3FbalNtyJdL7cRzCraCFUkNke
TLePkyD1Wq4nh+uF0u4kZGUehM0XQ563XcRfAcwc87xCnyzaQVhfSIrUxiUrIKuU
wYpX+0Q8WEEHmWKD8D3EeRS7YVuEF2NpVtfn0oon+YnxYS3aKz89moaF9ChPDA60
CpguH7fhsxtWa8oOkZwAd7LSP6Qvei2d4n5YPWOJ/cB0OqqWXAaDKyejNT0baNcw
j1cPDVr+RPTNpUKtUXAJnIprSiwNIiRoN+K07kmsUasa6XXfoljZ7NrqC81hUwsF
tNveWNNeP76AbjECsJ7UyN1WcbnOEd1vKHVeEmIcKoLUkXWsvobKtiDqMLGS4HNh
vBJhzvlM/fe1TEK4EuyhebNcxvR9zJz6A9PcmrOX3kiNk7HvPyrdePzFDjOV3+Rk
JYKSROaETU2gO9j2TuqJ
=aewC
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.