[Pkg-audacious-maintainers] Bug#486543:

[Stijn van Drongelen]

Is there a way to splice this bug into two bugs, one for the SIGSEGV
at boot, one for SIGILL at boot? It'll get pretty confusing
otherwise...


I see the following symptoms now:
1) When audacious starts and ~/.config/audacious/playlist.xspf exists,
audacious segfaults. GDB output attached as audacious-start.log
2) When I try to add a file in audacious that contains spaces in its
path, audacious segfaults. GDB output attached as audacious-add.log
3) When audacious exits, audacious segfaults. GDB output attached as
audacious-stop.log

Note regarding 1 and 2:
I can start audacious when I remove my playlist file. At that point, I
can also add files to the (now empty) playlist. I noticed however that
audacious still segfaults when I add certain items to the playlist.
There doesn't seem to be an obvious pattern. The crashes seem to be
unrelated to file/directory permissions, spaces or other weird
characters in path, or the hierarchies the files are in (I copied a
file from a hierarchy of files that never seem to fail into a
hierarchy that always seems to fail, and adding the copy to the
playlist didn't fail).

Main problems seem to be happening in vfs.c at line 159, and
ui_fileinfopopup.c at line 466.

vfs.c, line 159 (function vfs_fread):
    return file->base->vfs_fread_impl(ptr, size, nmemb, file);
The function only checks wether file is not NULL, but I think
file->base may be invalid at this point. Investigation of the struct
using GDB is attached in audacious-vfs.log.

Note how the octets of the addresses in the struct are all in the
ASCII plane, spelling "double free or corruption (f". How did that end
up in there?

ui_fileinfopopup.c, line 466 (function fileinfopopup_hide):
    if (GTK_WIDGET_VISIBLE(filepopup_win))
This pointer filepopup_win is never checked for nullity. I don't know
how exactly this problem works -- it seems that fileinfopopup_hide is
called as a result of gp->cleanup() (from plugin_system_cleanup's
frame), but I can't exactly see how. It does seem that gp->handle is 0
though.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: audacious-start.log
Type: text/x-log
Size: 2919 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-audacious-maintainers/attachments/20080702/54181edf/attachment-0012.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: audacious-add.log
Type: text/x-log
Size: 8273 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-audacious-maintainers/attachments/20080702/54181edf/attachment-0013.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: audacious-stop.log
Type: text/x-log
Size: 5430 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-audacious-maintainers/attachments/20080702/54181edf/attachment-0014.bin