cmus exists with Segmentation Fault

[Paul Kramer]

Hello,

everytime I exit cmus, it gives me a Segmentation Fault. As a result (I
think) it does not save the Library contents everytime. Meaning that it
reloads the library on almost every startup.

I think this problem has to do with the size of the library, because
when I only load part of my music, it does not exit with a segfault.

For reference: I am running version 2.3.4 on gentoo-linux

Thanks in advance,

Paul

[Johannes Weißl]

Hello Paul,

Post by Paul Kramer
everytime I exit cmus, it gives me a Segmentation Fault. As a result (I
think) it does not save the Library contents everytime. Meaning that it
reloads the library on almost every startup.
I think this problem has to do with the size of the library, because
when I only load part of my music, it does not exit with a segfault.
For reference: I am running version 2.3.4 on gentoo-linux

Thanks for the report! Can you try to compile cmus with debug flags and
send the gdb backtrace to the mailing list?

$ CFLAGS="-O0 -g" ./configure prefix=$HOME/cmus
$ make install
$ $HOME/cmus/bin/cmus

in another terminal:
$ gdb --pid=$(pgrep cmus)
(gdb) continue

in cmus:
:add ~/audio/library
:quit

in gdb (after segfault):
(gdb) backtrace



Johannes

[Paul Kramer]

Hello,

Thanks for the quick reply.

Here is the output:

[Thread 0xb4d63b70 (LWP 5072) exited]

Program received signal SIGSEGV, Segmentation fault.
0xb7710066 in realloc () from /lib/libc.so.6
(gdb) backtrace
#0 0xb7710066 in realloc () from /lib/libc.so.6
#1 0x0805af92 in xrealloc (buf=0xbfceece0, more=12) at xmalloc.h:54
#2 gbuf_grow (buf=0xbfceece0, more=12) at gbuf.c:29
#3 0x0805b13e in gbuf_add_bytes (buf=0xbfceece0, data=0xbfceec94,
len=12) at gbuf.c:51
#4 0x08051bce in write_ti (fd=<value optimized out>, buf=<value
optimized out>,
ti=<value optimized out>, offsetp=0x38) at cache.c:309
#5 0x00000008 in ?? ()
#6 0x00000038 in ?? ()
#7 0x00000008 in ?? ()
#8 0x0000002f in ?? ()
#9 0x00000008 in ?? ()
#10 0x00000037 in ?? ()
#11 0x00000006 in ?? ()
#12 0x00000011 in ?? ()
#13 0x00000007 in ?? ()
#14 0x0000000d in ?? ()
#15 0x00000030 in ?? ()
#16 0x00000020 in ?? ()
#17 0x00000006 in ?? ()
#18 0x00000005 in ?? ()
#19 0x00000005 in ?? ()
#20 0x00000005 in ?? ()
#21 0x0000000c in ?? ()
#22 0x00000003 in ?? ()
#23 0x0807712b in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)



Paul

Post by Johannes Weißl
Hello Paul,

Post by Paul Kramer
everytime I exit cmus, it gives me a Segmentation Fault. As a result (I
think) it does not save the Library contents everytime. Meaning that it
reloads the library on almost every startup.
I think this problem has to do with the size of the library, because
when I only load part of my music, it does not exit with a segfault.
For reference: I am running version 2.3.4 on gentoo-linux

Thanks for the report! Can you try to compile cmus with debug flags and
send the gdb backtrace to the mailing list?
$ CFLAGS="-O0 -g" ./configure prefix=$HOME/cmus
$ make install
$ $HOME/cmus/bin/cmus
$ gdb --pid=$(pgrep cmus)
(gdb) continue
:add ~/audio/library
:quit
(gdb) backtrace
Johannes

[Johannes Weißl]

Hello Paul,

thanks for the backtrace! There seems to have been a problem with the
debugging information though :-(. Can you send the backtrace again and
also the valgrind [1] output?

1. backtrace
new configure command:
$ CFLAGS="-O0 -g" LDFLAGS=$CFLAGS ./configure prefix=$HOME/cmus

and instead of the old gdb command, use:
$ gdb --pid=$(pgrep -f $HOME/cmus/bin/cmus)

2. valgrind
$ valgrind $HOME/cmus/bin/cmus 2>LOG
produce segfault and mail LOG file



[1] http://valgrind.org/


Johannes

[Paul Kramer]

When I do this, these are the outputs:

$ gdb --pid=$(pgrep -f $HOME/cmus/bin/cmus)
GNU gdb (Gentoo 7.2 p1) 7.2
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 "i686-pc-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>.
Attaching to process 2387
Reading symbols from /usr/lib/valgrind/memcheck-x86-linux...(no
debugging symbols found)...done.
0x3809807c in ?? ()
(gdb) continue
Continuing.

Program exited with code 052.
(gdb) backtrace
No stack.
(gdb)

Post by Johannes Weißl
Hello Paul,
thanks for the backtrace! There seems to have been a problem with the
debugging information though :-(. Can you send the backtrace again and
also the valgrind [1] output?
1. backtrace
$ CFLAGS="-O0 -g" LDFLAGS=$CFLAGS ./configure prefix=$HOME/cmus
$ gdb --pid=$(pgrep -f $HOME/cmus/bin/cmus)
2. valgrind
$ valgrind $HOME/cmus/bin/cmus 2>LOG
produce segfault and mail LOG file
[1] http://valgrind.org/
Johannes
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar

[Johannes Weißl]

Hello Paul,

Post by Johannes Weißl
$ gdb --pid=$(pgrep -f $HOME/cmus/bin/cmus)
[...]
(gdb) backtrace
No stack.

Maybe you tried to get a backtrace from `valgrind $HOME/cmus/bin/cmus`?
Just remove the "valgrind " and run pgrep with "-fx". But the valgrind
output is better anyhow!

Post by Johannes Weißl
==2387== Memcheck, a memory error detector
==2387== Invalid read of size 4
==2387== at 0x8051AC7: write_ti (cache.c:293)
==2387== Invalid free() / delete / delete[]
==2387== at 0x402596C: realloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2387== by 0x805AF91: gbuf_grow (xmalloc.h:54)
==2387== by 0x805B13D: gbuf_add_bytes (gbuf.c:51)
==2387== by 0x8051BCD: write_ti (cache.c:309)
==2387== Address 0xd is not stack'd, malloc'd or (recently) free'd

It looks like ti->filename is corrupted... which is very strange! Since
I can't reproduce the bug without your music collection, it is difficult
to solve. Maybe you can further investigate which file (or files)
trigger the segfault? I know it's a lot of work, but if you take a
logarithmic approach (test first half, test second half, ...), it might
be possible!


Johannes

[Paul Kramer]

Hello,

it seems the trouble is caused by the file

"11 - Aber die Liebe hort niemals auf.ogg"

The file name is okay. The problem was that it had some strange ID3-Tags.

There were a few "Comment"-Tags which seemed to contain the whole song
text and therefore some special characters. Maybe the problem was there.

After removing these tags, I didn't recieve any Segfaults so far. SO it
seems to me, that the problem is fixed.

If you want to investigate the problem further, I think I have a backup
of this file with the troublesome ID3-Tags.



Regards,
Paul

Post by Johannes Weißl
Hello Paul,

Post by Johannes Weißl
$ gdb --pid=$(pgrep -f $HOME/cmus/bin/cmus)
[...]
(gdb) backtrace
No stack.

Maybe you tried to get a backtrace from `valgrind $HOME/cmus/bin/cmus`?
Just remove the "valgrind " and run pgrep with "-fx". But the valgrind
output is better anyhow!

Post by Johannes Weißl
==2387== Memcheck, a memory error detector
==2387== Invalid read of size 4
==2387== at 0x8051AC7: write_ti (cache.c:293)
==2387== Invalid free() / delete / delete[]
==2387== at 0x402596C: realloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2387== by 0x805AF91: gbuf_grow (xmalloc.h:54)
==2387== by 0x805B13D: gbuf_add_bytes (gbuf.c:51)
==2387== by 0x8051BCD: write_ti (cache.c:309)
==2387== Address 0xd is not stack'd, malloc'd or (recently) free'd

It looks like ti->filename is corrupted... which is very strange! Since
I can't reproduce the bug without your music collection, it is difficult
to solve. Maybe you can further investigate which file (or files)
trigger the segfault? I know it's a lot of work, but if you take a
logarithmic approach (test first half, test second half, ...), it might
be possible!
Johannes
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar

[Johannes Weißl]

Fixes segfault.

Reported-by: Paul Kramer <***@gmx.de>
---
cache.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/cache.c b/cache.c
index 46752f5..4e0102d 100644
--- a/cache.c
+++ b/cache.c
@@ -284,15 +284,20 @@ static void write_ti(int fd, struct gbuf *buf, struct track_info *ti, unsigned i
unsigned int offset = *offsetp;
unsigned int pad;
struct cache_entry e;
- int len[65], count, i;
+ int *len, alloc = 64, count, i;

count = 0;
+ len = xnew(int, alloc);
e.size = sizeof(e);
e.duration = ti->duration;
e.mtime = ti->mtime;
len[count] = strlen(ti->filename) + 1;
e.size += len[count++];
for (i = 0; kv[i].key; i++) {
+ if (count + 2 > alloc) {
+ alloc *= 2;
+ len = xrenew(int, len, alloc);
+ }
len[count] = strlen(kv[i].key) + 1;
e.size += len[count++];
len[count] = strlen(kv[i].val) + 1;
@@ -313,6 +318,7 @@ static void write_ti(int fd, struct gbuf *buf, struct track_info *ti, unsigned i
gbuf_add_bytes(buf, kv[i].val, len[count++]);
}

+ free(len);
*offsetp = offset + pad + e.size;
}

[Gregory Petrosyan]

Post by Johannes Weißl
Fixes segfault.

Thanks! Merged to both maint and master.

Gregory