Bug 984229

Summary: [abrt] icedax-1.1.11-14.fc18: register_index_position: Process /usr/bin/icedax was killed by signal 11 (SIGSEGV)
Product: [Fedora] Fedora Reporter: jd1008
Component: glibcAssignee: Carlos O'Donell <codonell>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: codonell, fkluknav, fweimer, hhorak, jakub, law, pfrankli, schwab, spoyarek
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:c0dcd0b7073456a46b7a155f38b58676394cacef
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-08 03:39:44 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: dso_list
none
File: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status none

Description jd1008 2013-07-13 20:05:51 UTC
Description of problem:
I invoked 
 icedax dev=/dev/sr1 -vall cddb=0 -info-only

it crashed with the message:

index scan: 12...Memory fault(coredump)

Version-Release number of selected component:
icedax-1.1.11-14.fc18

Additional info:
reporter:       libreport-2.1.5
backtrace_rating: 4
cmdline:        cdda2wav dev=/dev/sr1 -vall -B cddb=1 -info-only
crash_function: register_index_position
executable:     /usr/bin/icedax
kernel:         3.9.9-201.fc18.x86_64
runlevel:       N 5
uid:            1008
var_log_messages: Jul 13 13:57:11 localhost abrt[4858]: Saved core dump of pid 4857 (/usr/bin/icedax) to /var/tmp/abrt/ccpp-2013-07-13-13:57:11-4857 (2686976 bytes)

Truncated backtrace:
Thread no. 1 (2 frames)
 #2 register_index_position at /usr/src/debug/cdrkit-1.1.11/icedax/toc.c:3093
 #3 ScanIndices at /usr/src/debug/cdrkit-1.1.11/icedax/toc.c:3199

Comment 1 jd1008 2013-07-13 20:05:55 UTC
Created attachment 773150 [details]
File: backtrace

Comment 2 jd1008 2013-07-13 20:05:58 UTC
Created attachment 773151 [details]
File: cgroup

Comment 3 jd1008 2013-07-13 20:06:00 UTC
Created attachment 773152 [details]
File: core_backtrace

Comment 4 jd1008 2013-07-13 20:06:03 UTC
Created attachment 773153 [details]
File: dso_list

Comment 5 jd1008 2013-07-13 20:06:06 UTC
Created attachment 773154 [details]
File: limits

Comment 6 jd1008 2013-07-13 20:06:08 UTC
Created attachment 773155 [details]
File: maps

Comment 7 jd1008 2013-07-13 20:06:11 UTC
Created attachment 773156 [details]
File: open_fds

Comment 8 jd1008 2013-07-13 20:06:13 UTC
Created attachment 773157 [details]
File: proc_pid_status

Comment 9 Frantisek Kluknavsky 2013-11-07 12:51:07 UTC
I can not reproduce the crash. Works for me.

Maybe it will be interesting for glibc people, since the crash was inside a call to malloc(16).

Comment 10 Jeff Law 2013-11-07 14:00:16 UTC
99.999% of the  time if you're getting an error in the allocator it's actually the fault of the user program or some library used by the user program, not glibc.

Comment 11 Carlos O'Donell 2013-11-08 03:39:44 UTC
The failure location is not particularly informative other than it's in the use of fast small bins which are acceptable to corruption since their information is encoded right beside the allocation on the same page of memory. Therefore any overwrites by the application can corrupt the fast bins. The only way to harden the allocator is to disable fast bins, and add checking (which you can do via the API).

Marking CLOSED/WORKSFORME based on Frantisek's comments.