Bug#584605: audacity: Continuing to backtrace

[Adrian Knoth]

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 at thur.de  	http://adi.thur.de	PGP/GPG: key via keyserver
-------------- next part --------------
A non-text attachment was scrubbed...
Name: audacity-debug.patch
Type: text/x-diff
Size: 1655 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20100614/fd434931/attachment.patch>