Bug#584605: audacity: Continuing to backtrace

[Dave Witbrodt]

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.