grip buffer overflow in intrepid

Bug #283658 reported by FRLinux on 2008-10-15
This bug affects 3 people
Affects Status Importance Assigned to Milestone
grip (Fedora)
Fix Released
grip (Ubuntu)

Bug Description

It seems that the latest upgrade of libc (from last night) has now rendered grip unstable, this is the trace I get when the program crashes without finishing to even rip a CD:

frlinux@ubuntu:~$ grip
*** buffer overflow detected ***: grip terminated
======= Backtrace: =========
======= Memory map: ========
08048000-08076000 r-xp 00000000 08:06 288997 /usr/bin/grip
08076000-08077000 r--p 0002e000 08:06 288997 /usr/bin/grip
08077000-0807b000 rw-p 0002f000 08:06 288997 /usr/bin/grip
0807b000-080a8000 rw-p 0807b000 00:00 0
093b1000-09d85000 rw-p 093b1000 00:00 0 [heap]
b2000000-b20d8000 rw-p b2000000 00:00 0
b20d8000-b2100000 ---p b20d8000 00:00 0
b21dd000-b228a000 rw-p b21dd000 00:00 0
b228a000-b228b000 ---p b228a000 00:00 0
b228b000-b2a8b000 rw-p b228b000 00:00 0
b2a8b000-b2a8c000 r-xp 00000000 08:06 345134 /usr/lib/gtk-2.0/2.10.0/immodules/
b2a8c000-b2a8d000 r--p 00000000 08:06 345134 /usr/lib/gtk-2.0/2.10.0/immodules/
b2a8d000-b2a8e000 rw-p 00001000 08:06 345134 /usr/lib/gtk-2.0/2.10.0/immodules/
b2a8e000-b2ace000 rw-p b2a8e000 00:00 0
b2ace000-b2eb1000 r--p 00000000 08:06 530153 /usr/share/fonts/truetype/unfonts/UnBatangBold.ttf
b2eb1000-b2f9b000 rw-p b2eb1000 00:00 0
b2f9b000-b2fb4000 r--p 00000000 08:06 375721 /usr/share/fonts/type1/gsfonts/n022004l.pfb
b2fb4000-b2fc0000 r--p 00000000 08:06 342641 /usr/share/fonts/truetype/ttf-bitstream-vera/VeraMoBd.ttf
b2fc0000-b3001000 rw-p b2fc0000 00:00 0
b3001000-b3384000 r--p 00000000 08:06 530152 /usr/share/fonts/truetype/unfonts/UnBatang.ttf
b3384000-b33b5000 rw-p b3384000 00:00 0
b33b5000-b3b1f000 r--p 00000000 08:06 399058 /usr/share/fonts/truetype/kochi/kochi-gothic-subst.ttf
b3b1f000-b3b78000 rw-p b3b1f000 00:00 0
b3b78000-b4f8d000 r--p 00000000 08:06 376336 /usr/share/fonts/truetype/arphic/uming.ttc
b4f8d000-b4fed000 rw-p b4f8d000 00:00 0
b4fed000-b6402000 r--p 00000000 08:06 376336 /usr/share/fonts/truetype/arphic/uming.ttc
b641a000-b6427000 r--p 00000000 08:06 342643 /usr/share/fonts/truetype/ttf-bitstream-vera/VeraMono.ttf
b6427000-b646e000 r--p 00000000 08:06 400434 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono-Bold.ttf
b646e000-b64ba000 r--p 00000000 08:06 400433 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono.ttf
b64ba000-b64bb000 r--p 00000000 08:06 433597 /usr/share/vte/termcap/xterm
b64bb000-b65bf000 rw-p b64bb000 00:00 0
b65bf000-b6654000 r--p 00000000 08:06 400431 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf
b6654000-b6656000 r-xp 00000000 08:06 342928 /usr/lib/pango/1.6.0/modules/
b6656000-b6657000 r--p 00001000 08:06 342928 /usr/lib/pango/1.6.0/modules/
b6657000-b6658000 rw-p 00002000 08:06 342928 /usr/lib/pango/1.6.0/modules/
b6658000-b665e000 r--s 00000000 08:06 537625 /var/cache/fontconfig/945677eb7aeaf62f1d50efc3fb3ec7d8-x86.cache-2
b665e000-b6661000 r--s 00000000 08:06 537641 /var/cache/fontconfig/e383d7ea5fbe662a33d9b44caf393297-x86.cache-2
b6661000-b6662000 r--s 00000000 08:06 537640 /var/cache/fontconfig/4c73fe0c47614734b17d736dbde7580a-x86.cache-2
b6662000-b6665000 r--s 00000000 08:06 537639 /var/cache/fontconfig/a755afe4a08bf5b97852ceb7400b47bc-x86.cache-2
b6665000-b666c000 r--s 00000000 08:06 540746 /var/cache/fontconfig/6d41288fd70b0be22e8c3a91e032eec0-x86.cache-2
b666c000-b666f000 r--s 00000000 08:06 537637 /var/cache/fontconfig/de156ccd2eddbdc19d37a45b8b2aac9c-x86.cache-2
b666f000-b6677000 r--s 00000000 08:06 537636 /var/cache/fontconfig/e3de0de479f42330eadf588a55fb5bf4-x86.cache-2
b6677000-b6682000 r--s 00000000 08:06 537635 /var/cache/fontconfig/0f34bcd4b6ee430af32735b75db7f02b-x86.cache-2
b6682000-b6685000 r--s 00000000 08:06 537633 /var/cache/fontconfig/de9486f0b47a4d768a594cb4198cb1c6-x86.cache-2
b6685000-b668c000 r--s 00000000 08:06 537632 /var/cache/fontconfig/d52a8644073d54c13679302ca1180695-x86.cache-2
b668c000-b6692000 r--s 00000000 08:06 537624 /var/cache/fontconfig/089dead882dea3570ffc31a9898cfb69-x86.cache-2
b6692000-b6694000 r--s 00000000 08:06 537627 /var/cache/fontconfig/e13b20fdb08344e0e664864cc2ede53d-x86.cache-2
b6694000-b66f4000 rw-s 00000000 00:09 720913 /SYSV00000000 (deleted)
b66f4000-b66fa000 r-xp 00000000 08:06 345062 /usr/lib/gtk-2.0/2.10.0/loaders/
b66fa000-b66fb000 r--p 00005000 08:06 345062 /usr/lib/gtk-2.0/2.10.0/loaders/
b66fb000-b66fc000 rw-p 00006000 08:06 345062 /usr/lib/gtk-2.0/2.10.0/loaders/
b66fc000-b675c000 rw-s 00000000 00:09 688139 /SYSV00000000 (deleted)
b675c000-b67f2000 rw-p b675c000 00:00 0
b67f2000-b6811000 r-xp 00000000 08:06 362546 /usr/lib/gtk-2.0/2.10.0/engines/
b6811000-b6812000 r--p 0001e000 08:06 362546 /usr/lib/gtk-2.0/2.10.0/engines/
b6812000-b6813000 rw-p 0001f000 08:06 362546 /usr/lib/gtk-2.0/2.10.0/engines/
b6813000-b681a000 r--p 00000000 08:06 318601 /usr/share/locale-langpack/fr/LC_MESSAGES/
b681a000-b681e000 r-xp 00000000 08:06 343263 /usr/lib/gtk-2.0/2.10.0/loaders/
b681e000-b681f000 r--p 00003000 08:06 343263 /usr/lib/gtk-2.0/2.10.0/loaders/
b681f000-b6820000 rw-p 00004000 08:06 343263 /usr/lib/gtk-2.0/2.10.0/loaders/
b6820000-b6842000 r--p 00000000 08:06 684227 /usr/share/locale-langpack/fr/LC_MESSAGES/
b6842000-b684d000 r--p 00000000 08:06 684406 /usr/share/locale-langpack/fr/LC_MESSAGES/
b684d000-b684e000 rw-p b684d000 00:00 0
b684e000-b6851000 r--p 00000000 08:06 318636 /usr/share/locale-langpack/fr/LC_MESSAGES/
b6851000-b685b000 r-xp 00000000 08:06 277062 /lib/tls/i686/cmov/
b685b000-b685c000 r--p 00009000 08:06 277062 /lib/tls/i686/cmov/
b685c000-b685d000 rw-p 0000a000 08:06 277062 /lib/tls/i686/cmov/
b685d000-b6866000 r-xp 00000000 08:06 277065 /lib/tls/i686/cmov/
b6866000-b6867000 r--p 00008000 08:06 277065 /lib/tls/i686/cmov/
b6867000-b6868000 rw-p 00009000 08:06 277065 /lib/tls/i686/cmov/
b6868000-b686f000 r-xp 00000000 08:06 277060 /lib/tls/i686/cmov/
b686f000-b6870000 r--p 00006000 08:06 277060 /lib/tls/i686/cmov/
b6870000-b6871000 rw-p 00007000 08:06 277060 /lib/tls/i686/cmov/
b6871000-b6883000 r--p 00000000 08:06 684418 /usr/share/locale-langpack/fr/LC_MESSAGES/
b6883000-b68aa000 r--p 00000000 08:06 318626 /usr/share/locale-langpack/fr/LC_MESSAGES/
b68aa000-b68b3000 r--p 00000000 08:06 684371 /usr/share/locale-langpack/fr/LC_MESSAGES/
b68b3000-b68b4000 r-xp 00000000 08:06 287632 /usr/lib/gconv/
b68b4000-b68b5000 r--p 00001000 08:06 287632 /usr/lib/gconv/
b68b5000-b68b6000 rw-p 00002000 08:06 287632 /usr/lib/gconv/
b68b6000-b68bc000 r--p 00000000 08:06 285516 /usr/share/locale/fr/LC_MESSAGES/
b68bc000-b68fb000 r--p 00000000 08:06 309678 /usr/lib/locale/fr_FR.utf8/LC_CTYPE
b68fb000-b69dc000 r--p 00000000 08:06 309681 /usr/lib/locale/fr_FR.utf8/LC_COLLATE
b69dc000-b69e1000 rw-p b69dc000 00:00 0
b69e1000-b69e4000 r-xp 00000000 08:06 277146 /lib/
b69e4000-b69e5000 rw-p 00002000 08:06 277146 /lib/
b69e5000-b6aa8000 r-xp 00000000 08:06 285978 /usr/lib/
b6aa8000-b6aaa000 r--p 000c2000 08:06 285978 /usr/lib/
b6aaa000-b6aad000 rw-p 000c4000 08:06 285978 /usr/lib/
b6aad000-b6aae000 rw-p b6aad000 00:00 0
b6aae000-b6ac3000 r-xp 00000000 08:06 277058 /lib/tls/i686/cmov/
b6ac3000-b6ac4000 r--p 00014000 08:06 277058 /lib/tls/i686/cmov/
b6ac4000-b6ac5000 rw-p 00015000 08:06 277058 /lib/tls/i686/cmov/
b6ac5000-b6ac7000 rw-p b6ac5000 00:00 0
b6ac7000-b6ac9000 r-xp 00000000 08:06 277137 /lib/
b6ac9000-b6acb000 rw-p 00001000 08:06 277137 /lib/
b6acb000-b6ad2000 r-xp 00000000 08:06 287589 /usr/lib/
b6ad2000-b6ad3000 r--p 00006000 08:06
[1]+ Abandon (core dumped) grip

Download full text (4.6 KiB)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4

Description of problem:
I get this giant buffer overflow when ripping. It occurs at random times in the beginning of the ripping process (track 1-3 of an 11 track cd). My FC4 is a fresh install.

Also Grip often completely fails ripping because of this:

Error trying to open /dev/hdd exclusively (Device or resource busy). retrying in 1 second.

Then later it will crash with the usual buffer overflow:

*** buffer overflow detected ***: grip terminated
======= Backtrace: =========
======= Memory map: ========
00111000-00123000 r-xp 00000000 03:05 1460009 /usr/lib/
00123000-00124000 rwxp 00011000 03:05 1460009 /usr/lib/
00124000-00185000 r-xp 00000000 03:05 1460018 /usr/lib/
00185000-0018c000 rwxp 00061000 03:05 1460018 /usr/lib/
0018c000-001b2000 r-xp 00000000 03:05 1460020 /usr/lib/ rwxp 00026000 03:05 1460020 /usr/lib/ rwxp 001b5000 00:00 0
001b6000-001b7000 r-xp 00000000 03:05 1598576 /usr/X11R6/lib/X11/locale/lib/common/
001b7000-001b8000 rwxp 00000000 03:05 1598576 /usr/X11R6/lib/X11/locale/lib/common/
001b8000-001ca000 r-xp 00000000 03:05 1460021 /usr/X11R6/lib/
001ca000-001cb000 rwxp 00012000 03:05 1460021 /usr/X11R6/lib/
001cb000-001dc000 r-xp 00000000 03:05 1449262 /usr/lib/
001dc000-001dd000 rwxp 00011000 03:05 1449262 /usr/lib/
001dd000-001e4000 r-xp 00000000 03:05 1452110 /usr/lib/
001e4000-001e5000 rwxp 00007000 03:05 1452110 /usr/lib/
001e5000-001ec000 r-xp 00000000 03:05 1460035 /usr/lib/
001ec000-001ed000 rwxp 00006000 03:05 1460035 /usr/lib/
001ed000-001ef000 r-xp 00000000 03:05 621895 /lib/
001ef000-001f0000 rwxp 00001000 03:05 621895 /lib/
001f2000-002a6000 r-xp 00000000 03:05 1454020 /usr/lib/
002a6000-002af000 rwxp 000b3000 03:05 1454020 /usr/lib/
002af000-002d5000 r-xp 00000000 03:05 1460066 /usr/lib/
002d5000-002d8000 rwxp 00025000 03:05 1460066 /usr/lib/libgnomecanvas-...


Does this happen with every CD you try to rip, or does it only occur with
certain CDs?
Could it be that your harddisk is full and it crashes therefore somewhere?
Do you have the debuginfo for grip installed?
Have you contacted upstream?

As I cannot reprodruce it I am currently only guessing...

Yes, it happens with all my CDs drive. HDD isn't full but I'm writing to a FAT32
partition. Maybe that's the problem. I will try to install the debug and get back.

*** Bug 165005 has been marked as a duplicate of this bug. ***

Why the heck couldn't I find this bug when I searched extensively! Same problem
here and my duplicate report bug 165005 contains most of my information. I'm
also ripping to a FAT32 partition, but previously (FC3) grip ripped to it fine.
Hard disk nowhere near full.

To answer Adrian's question on the other bug - just renamed ~/.grip so it's
ripping to ogg by default and to ext3: no crash. Changed new config to rip to
ogg on FAT32 - no crash. Changed ripper from new default of cdparanoia back to
my previous setting of cdda2wav - no crash writing to either filesystem. In
short, I've done about 30 rips and encodes varying every variable and think I've
found at least one hot-point causing a crash every time:

doid3v2 1 (Add ID3v2 tags to encoded files)

when writing the mp3 to *either* filesystem (FAT32 or ext3). Turning
no_lower_case, no_underscore and allow_high_bits don't make any difference - it
crashes with them on or off. I don't have any allow_these_chars set and am using
the default UTF-8 settings. And the crash occurs right at the end of the
encoding phase, just when the tags will be being written. Or presumably when the
.wav is being deleted, but I've disabled this and the crash still occurs. Just
to emphasise, the filesystem is irrelevant at least for this crash.

The odd thing is that there's nothing special about the problematic tracks, yet
the crashes are predictable with it. No foreign language accents in grip, nor
do they have when viewed at

I don't have the debuginfo package installed (do I have to rebuild the SRPM to
get this, or is it in a repository?). Done a lot of debugging on this today so I
have to stop for now - maybe Benjamin could try and reproduce this or this
provides some more clues to Adrian. If it's relevant:

% rpm -q taglib taglib-devel

So for now my workaround: turn off ID3 v2 tagging, and write them with easytag
later. Of course there may be other case crashes with this turned off - I'll try
to add to this bugzilla if I find them.

My hardware (although probably irrelevant):
Probing IDE interface ide1...
ide1 at 0x170-0x177,0x376 on irq 15
hdc: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20

Yes, debuginfo packages are found in the Fedora Extras repository, ./debug
sub-directory. A full backtrace -- --
would be interesting, since you seem to be able to reproduce this crash.

taglib is not used here.

libid3 is used, so grip-debuginfo and libid3-debuginfo should be installed at least.

Created attachment 117424
patch for one buffer overflow in id3.c

This is one sprintf buffer overflow in grip's ID3v2 creation.

Thanks Michael - I've applied your patch to the current SRPM and rebuilt it, and
it certainly seems to fix the specific ID3 v2 writing overflows above - can't
reproduce them for now. I'd suggest leaving this bug open for a while to allow
Benjamin and any others to confirm his settings - this may not be the only problem.

Will install debuginfos if I get more crashes.

Michael, thanks for your help. I will apply the patch and release a new package

Hmm. Two system hangs (complete, not even responsive to SysRq) using the patched
grip. Syslog messages:
Aug 4 14:57:39 localhost kernel: hdc: DMA timeout retry
Aug 4 14:57:39 localhost kernel: hdc: timeout waiting for DMA
Aug 4 14:57:39 localhost kernel: hdc: status error: status=0x58 { DriveReady
SeekComplete DataRequest }
Aug 4 14:57:39 localhost kernel: ide: failed opcode was: unknown
Aug 4 14:57:39 localhost kernel: hdc: drive not ready for command

Restored the current unpatched Extras grip and no hangs. Feasible that the patch
could cause this?

Back to the original grip, with debuginfo packages installed (I assume you meant

% rpm -q grip grip-debuginfo libid3tag libid3tag-debuginfo

- backtrace attached next.

Created attachment 117460
Backtrace of ID3 v2 writing buffer overflow

* libid3tag is not used by grip, id3lib is.

* The patch does not cause any hangs. It does not introduce any regression and
does not have any effect onto the kernel/driver level.

> comment=0x8e4b9d8 "", genre=131 '\203', tracknum=5 '\005',

Thanks for the more detailed bracktrace. The "genre" value in there (three
digits wide) confirms that the patch fixes the buffer overflow.

Also found upstream:

  Grip crashes after one track is ripped but not for all CDs

Also patched in exactly the same way:

  ID3v2TagFile() insufficient genre buffer size bugfix

Hmm thanks. So my lockups were coincidental, possibly hardware? I can see the
sense in your patch, harmless and can't cause a lockup - but experienced two in
3 CDs and never have before, and none again having restored the Extras RPM.
Wondering if there's another bug in grip which your fix clears the way for...
will report back here if I see more.

I was finally able to reproduce this error. The important part is to select
'Indie' as genre and then it crashes. The patch fixes the error for me.

I have requested a new build of grip with this patch included and a new version
will be available shortly and I will close this bug.
If you still have the same problem then just re-open the bug.
For kernel hangs you should open another bug.

FRLinux (frlinux) wrote :

Actually, might have been too hasty about this, seems to be related to the CD (which is not copy protected as far as I can tell) :

[ 918.176129] ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 918.176155] ata4.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
[ 918.176158] cdb 1b 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
[ 918.176160] res 40/00:03:00:00:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
[ 918.176168] ata4.00: status: { DRDY }
[ 918.456100] ata4: soft resetting link
[ 918.636580] ata4.00: configured for UDMA/33
[ 918.636631] ata4: EH complete
[ 948.405358] end_request: I/O error, dev sr0, sector 0

Edward (edward-coffey) wrote :

I'm getting the same issue, it seems I can rip without a problem, but if I choose Rip+Encode it dies around halfway through encoding the first track. It is using Lame as its encoder.

Fabian A. Scherschel (fabsh) wrote :
Download full text (9.0 KiB)

Same as Edward. I think that confirms it (setting to "confirmed"). Here's the output from the CLI:

fabsh@serenity:~$ grip
*** buffer overflow detected ***: grip terminated
======= Backtrace: =========
======= Memory map: ========
08048000-08076000 r-xp 00000000 08:01 811188 /usr/bin/grip
08076000-08077000 r--p 0002e000 08:01 811188 /usr/bin/grip
08077000-0807b000 rw-p 0002f000 08:01 811188 /usr/bin/grip
0807b000-080a8000 rw-p 0807b000 00:00 0
08c42000-097c4000 rw-p 08c42000 00:00 0 [heap]
b001a000-b001b000 ---p b001a000 00:00 0
b001b000-b081b000 rw-p b001b000 00:00 0
b081b000-b1b46000 r--p 00000000 08:03 17123319 /home/fabsh/.icons/DesertII/icon-theme.cache
b1b46000-b2f5b000 r--p 00000000 08:01 939867 /usr/share/fonts/truetype/arphic/uming.ttc
b2f5b000-b2fa8000 r--p 00000000 08:01 334699 /usr/share/fonts/truetype/msttcorefonts/Courier_New_Bold.ttf
b2fa8000-b332b000 r--p 00000000 08:01 940003 /usr/share/fonts/truetype/unfonts/UnBatang.ttf
b332b000-b335c000 rw-p b332b000 00:00 0
b3ac6000-b3b1f000 rw-p b3ac6000 00:00 0
b3c00000-b3cad000 rw-p b3c00000 00:00 0
b3cad000-b3d00000 ---p b3cad000 00:00 0
b3e70000-b3f1d000 rw-p b3e70000 00:00 0
b3f1d000-b3f2c000 r-xp 00000000 08:01 228518 /lib/
b3f2c000-b3f2d000 r--p 0000f000 08:01 228518 /lib/
b3f2d000-b3f2e000 rw-p 00010000 08:01 228518 /lib/
b3f2e000-b3f5f000 r-xp 00000000 08:01 809591 /usr/lib/
b3f5f000-b3f62000 rw-p 00030000 08:01 809591 /usr/lib/
b3f62000-b3f92000 r-xp 00000000 08:01 809868 /usr/lib/
b3f92000-b3f94000 r--p 0002f000 08:01 809868 /usr/lib/
b3f94000-b3f95000 rw-p 00031000 08:01 809868 /usr/lib/
b3f95000-b3f96000 rw-p b3f95000 00:00 0
b3f96000-b3fc7000 r-xp 00000000 08:01 810230 /usr/lib/
b3fc7000-b3fc8000 r--p 00030000 08:01 810230 /usr/lib/
b3fc8000-b3fc9000 rw-p 00031000 08:01 810230 /usr/lib/
b3fc9000-b3fe1000 r-xp 00000000 08:01 840810 /usr/lib/gio/modules/
b3fe1000-b3fe2000 r--p 00017000 08:01 840810 /usr/lib/gio/modules/
b3fe2000-b3fe3000 rw-p 00018000 08:01 840810 /usr/lib/gio/modules/
b3fe3000-b42e5000 r--p 00000000 08:0...


Changed in grip:
status: New → Confirmed
Michael (m-iostreams) wrote :

Having same issue, with only one cd, so far.
Lame is the encoder, all paranoia is disabled, first song rips, and begins encoding, as soon as second song starts ripping - grip aborts with the same output as above.
I can rip the whole cd without problem, but rip+encode causes grip to fail on one disk only.

On Sat, Nov 8, 2008 at 3:18 PM, Michael <email address hidden> wrote:
> Having same issue, with only one cd, so far.
> Lame is the encoder, all paranoia is disabled, first song rips, and begins encoding, as soon as second song starts ripping - grip aborts with the same output as above.
> I can rip the whole cd without problem, but rip+encode causes grip to fail on one disk only.

That is what i don't understand, out of 10 CDs i ripped so far, only
one had the same symptoms. I ended up ripping the CD with cdparanoia
(not the integrated one from grip, the official one) then used lame on
the cli to encode files.


arndtc (arndtc) wrote :
Download full text (9.1 KiB)

I'm seeing the same problem.
I can rip fine, but when I try to do rip + encode, it dies about half way through the first track.

I can't find another ripper that is as user friendly as grip, and would like to see this fixed, so I can continue ripping my CDs.

*** buffer overflow detected ***: grip terminated
======= Backtrace: =========
======= Memory map: ========
08048000-08076000 r-xp 00000000 09:02 2867799 /usr/bin/grip
08076000-08077000 r--p 0002e000 09:02 2867799 /usr/bin/grip
08077000-0807b000 rw-p 0002f000 09:02 2867799 /usr/bin/grip
0807b000-080a8000 rw-p 0807b000 00:00 0
08f3d000-097ae000 rw-p 08f3d000 00:00 0 [heap]
b1fe2000-b1fe3000 ---p b1fe2000 00:00 0
b1fe3000-b27e3000 rw-p b1fe3000 00:00 0
b27e3000-b2f4d000 r--p 00000000 09:02 3025121 /usr/share/fonts/truetype/kochi/kochi-gothic-subst.ttf
b2f4d000-b32d0000 r--p 00000000 09:02 3237755 /usr/share/fonts/truetype/unfonts/UnBatang.ttf
b32d0000-b3301000 rw-p b32d0000 00:00 0
b39fe000-b3a16000 r--p 00000000 09:02 1767864 /usr/share/fonts/type1/gsfonts/n022003l.pfb
b3a16000-b3a2f000 r--p 00000000 09:02 1767865 /usr/share/fonts/type1/gsfonts/n022004l.pfb
b3a2f000-b3a6b000 r--p 00000000 09:02 1095684 /usr/share/fonts/truetype/msttcorefonts/Courier_New_Italic.ttf
b3a6b000-b3ac4000 rw-p b3a6b000 00:00 0
b3f3d000-b3f6e000 r-xp 00000000 09:02 2863878 /usr/lib/
b3f6e000-b3f71000 rw-p 00030000 09:02 2863878 /usr/lib/
b3f71000-b3fa1000 r-xp 00000000 09:02 2863466 /usr/lib/
b3fa1000-b3fa3000 r--p 0002f000 09:02 2863466 /usr/lib/
b3fa3000-b3fa4000 rw-p 00031000 09:02 2863466 /usr/lib/
b3fa4000-b3fa5000 rw-p b3fa4000 00:00 0
b3fa5000-b3fd6000 r-xp 00000000 09:02 2866942 /usr/lib/
b3fd6000-b3fd7000 r--p 00030000 09:02 2866942 /usr/lib/
b3fd7000-b3fd8000 rw-p 00031000 09:02 2866942 /usr/lib/
b3fd8000-b3ff0000 r-xp 00000000 09:02 3074424 /usr/lib/gio/modules/
b3ff0000-b3ff1000 r--p 00017000 09:02 3074424 /usr/lib/gio/modules/
b3ff1000-b3ff2000 rw-p 00018000 09:02 3074424 /usr/lib/gio/modules/
b3ff2000-b4418000 r--p 00000000 09:02 2943602 /usr/share/icons/hicolor/icon-theme.cache
b4418000-b4af6000 r--p 00000000 09:0...



I have the same problem (same dump), but it seems to be related to the insertion of the ID3 tags.
I managed to extract and encode the full cd by disabling the ID3 tags.


Jesse Bye (jesse-bye) wrote :

I encountered this problem when I attempted to rip a CD with Japanese titles. I am guessing it has something to do with the treatment of special characters (maybe UTF-8)? It would be nice to get this fixed; however, I was able to rip the CD (including correct tags) with abcde.

Scott (shendric) wrote :

It seems that it's the *v2* tags that are causing the problem. If I turn off "ID3v2" then the program no longer crashes, even though I have "ID3" tags on still.

I had the very same problem (buffer overflow error) after upgrading to Intrepid with 2 CDs.
I confirm that after turning off ID3v2, it worked fine on those 2.

arndtc (arndtc) wrote :

Thanks for the tip that the problem is with the writing of the ID3v2 tags.

I've found a work around. Its a bit painful, but it works.
I can add the tag information to the command line.

I sure wish there was work happening to fix GRiP. Its the best Ripper program I've found. I've tried many others, but found them either too complicated, or didn't get the features that I was trying to find.

Avi Schwartz (le-avion) wrote :

Yes, thanks for the tip. For now I use ID3 but that means that I have to go and use another tool (EasyTag) to fix all the long tags that get chopped off with ID3. Please fix this problem...

Hajime Fujita (hfujita) wrote :


The attached patch worked for me.

This patch fixes a buffer overflow bug in id3.c.
I found that sometimes the genre argument to ID3v2TagFile() exceeds 100
(in my test case it was 145).
In this case, sprintf() call in id3.c:L281 overruns the buffer.
The maximum length of the formatted string is 5 (3-digits and two parentheses),
so 6 bytes (five characters + one NULL character) is enough for the buffer.

Hajime Fujita (hfujita) wrote :

The above patch is for grip (3.3.1-15build1) on intrepid.
I tested the patch on Intrepid/amd64 (I believe there's no architecture-dependency with this patch, though).

Avi Schwartz (le-avion) wrote :

Hajime, are you sure it has to do with the genre? In my case the genre was "Classical" and it still crashed.

in any case your patch seems to work in most situation but there is still a problem although I am not sure it is related.

If the track name is very long, that is greater then 95 characters, the file name gets truncated and the ripped and encoded file names end up being the same causing the encoding to fail since it is overwriting the ripped file.

Hajime Fujita (hfujita) wrote :

I tried three CDs which led grip to crash before, and all of them were ripped (and tagged) successfully with the patch.
Genre for those discs were "Anime" for two and "JPop" for one.

The genre "Classical" will be mapped to the value of 32, so I think it shouldn't be a problem even if you use the current (buggy) version.
That's strange... perhaps there might be other issue in the code...

If you are able to provide an ID3 tag which can reproduce the problem, it will really help us.

DannyArmstrong (detarmstrong) wrote :

Grip crashes for me when attempting to encode the song "I like van halen because my sister says they are cool." Turning off id3v2 fixes the problem.

Same problem here. The inexistent genre was the problem.

ID3 has a limited and american centric set of genres:

Grip always ignored if you put a invalid genre. Now I tried to put Samba and it crashed. Everything works fine after changing the genre to Alternative. Other CDs worked fine because they had an existent genre.

I'd love to have Grip put my selected genre in the id3 tag.

Fabian A. Scherschel (fabsh) wrote :

@Paulo: Aha! Good to know that! Seems "Garage Rock" is no genre after all...

Maybe we should Grip warn people with a message or something. After all, you can always change the tag to whatever you want with EasyTAG afterwards...

zig59 (zig-59) wrote :

Converting cd to mp3 using lame I was getting the same crash here selecting 'Power Ballad' for the album genre from the dropdown list.

Selecting 'Rock', which I normally have it set to, saw it rip and encode with no problems (using id3v2).

Ajay (ajaygautam) wrote :

The (valid) "Speech" genre crashes Grip
Am trying to convert an audio book to mp3

Grip with id3v2 disabled passed the crash point WooHoo!

Glad to get grip working again.

Alan Robertson (alanr-unix) wrote :

I have this same problem - and disabling id3v2 fixes it for me also.

Peter Gaultney (petergaultney) wrote :

I have had this same problem - rather, a friend of mine did, on Ubuntu Jaunty x86.

The output from grip --verbose is almost identical to what is listed for the bug.

Changed in grip (Fedora):
status: Unknown → Fix Released
sam tygier (samtygier) wrote :

Just to note, Grip is no longer being maintained by upstream or debian, it will be dropped from Karmic (unless someone takes over maintenance), hence the change of this being fixed is small.

Peter Gaultney (petergaultney) wrote :

This is probably the wrong place to ask, but I guess that makes me wonder: is the old maintainer looking for anyone to take over? I might volunteer. It would certainly take a few weeks to get up to speed on the codebase, but Grip is a program worth maintaining, in my opinion.

sam tygier (samtygier) wrote :

you could start trying to contact Mike Oliphant from his email address at (click his name at the bottom of the page), or . you could also try contacting Daniel Baumann

i also suggest looking at the more active ripping progects, maybe you could add to them anything that the lack relative to grip.

Ben Johnson (benj-visi) wrote :

If you are using LAME as the encoder, a good work around is tagging files with lame instead instead of letting Grip do it.
 1. on the Config / ID3 Screen, turn off all ID3 tags
 2. on the Config / Encode / Encoder screen, set
    Encoder: lame
    Encoder executable: /usr/bin/lame
    Encoder command line: -h -b %b --add-id3v2 --tt %n --ta %a --tl %d --ty %y --tc "Grip 3.3.1 / Lame 3.98" --tn "%t/%N" --tg "%G" %w %m.%x
    Encode file extension: mp3
    Encode file format: /mp3riptmp/%A - %d/%a - %n

I don't know if it helps but I had the same problem and each time, changing the genre did solve the problem.

Here are the CD, old genre (that lead to a crash) and new genre (that made grip work well) :

Qemists - Join the Q Drum & Bass -> Electronic
Brigitte Fontaine - Morceaux De Choix Chanson -> Other
The Beatles - The Early Tapes Of The Beatles Beat -> Rock

It looks like every genre after "Other" makes grip crash.

Alessio Treglia (quadrispro) wrote :

grip is no longer maintained and it has been removed since Karmic.

Keeping opened only for Intrepid.

Changed in grip (Ubuntu):
status: Confirmed → Won't Fix
Robert Sander (gurubert) wrote :

If grip is not in karmic any more, what is the recommended feature comparable alternative?

sam tygier (samtygier) wrote :

personally i switched to sound-juicer. doesn't have quite so many options, but can still do everything i need it to. also it uses musicbrainz instead of CDDB which gives more consistent results (eg 'REM' vs 'R.E.M.').

there are some more listed at , or have a search in the forum.

zig59 (zig-59) wrote :

I've switched to RipperX. You may also need to manually install (Synaptic) Lame.

However, I strongly recommend reading: for setting up RipperX (note the manual amendment of the config file)
and for general VBR info.

Note that the last url tries to throw a pop-up (not needed) which Firefox auto-blocked. Just thought I'd mention it.

My encoder line reads: Encoder::fullCommand = lame --nohist -V2 --vbr-new -q0 --lowpass 19.7 -b 96
This suits me but ymmv :)


Alex Valavanis (valavanisalex) wrote :

I'm closing the report for Intrepid because it reached end-of-life on 30 April 2010. Can anyone confirm whether this still exists in Jaunty? Grip has been removed from Ubuntu since Karmic.

Changed in grip (Ubuntu Intrepid):
status: New → Invalid
Changed in grip (Fedora):
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.