Bug 136982
Summary: | k3b send sigabrt when it start up. | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | MASA.H <masahase> |
Component: | kernel | Assignee: | Dave Jones <davej> |
Status: | CLOSED ERRATA | QA Contact: | Brian Brock <bbrock> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 4 | CC: | pfrields |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-12-28 02:21:17 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: | |||
Bug Depends On: | 134822 | ||
Bug Blocks: |
Description
MASA.H
2004-10-24 18:54:16 UTC
could you append the coredump? or install http://people.redhat.com/~harald/k3b-debuginfo-0.11.14-2.i386.rpm and then give me the traceback? Please! Thanks! *** glibc detected *** double free or corruption: 0x0937d008 *** Does k3b run from a terminal, do you see anything like this? Also please run from terminal in this way: MALLOC_CHECK_=0 k3b Does it start when it otherwise would have failed? $MALLOC_CHECK_=0 k3b Invalid entry (empty key) at /home/masahase/.kde/share/config/k3brc:22 kbuildsycoca running... Reusing existing ksycoca terminate called after throwing an instance of 'std::bad_alloc' what(): St9bad_alloc KCrash: Application 'k3b' crashing... Mutex destroy failure: ããã¤ã¹ãããã¯ãªã½ã¼ ã¹ããã¸ã¼ç¶æã§ã ICE default IO error handler doing an exit(), pid = 14637, errno = 0 After installing k3b-debuginfo. Using host libthread_db library "/lib/tls/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -151188768 (LWP 14895)] [KCrash handler] #4 0x007247a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #5 0x00764955 in raise () from /lib/tls/libc.so.6 #6 0x00766319 in abort () from /lib/tls/libc.so.6 #7 0x00b7c6eb in __gnu_cxx::__verbose_terminate_handler () from /usr/lib/libstdc++.so.6 #8 0x00b7a3fd in __cxa_call_unexpected () from /usr/lib/libstdc++.so.6 #9 0x00b7a432 in std::terminate () from /usr/lib/libstdc++.so.6 #10 0x00b7a57b in __cxa_throw () from /usr/lib/libstdc++.so.6 #11 0x00b7a9cc in operator new () from /usr/lib/libstdc++.so.6 #12 0x00b7aa69 in operator new[] () from /usr/lib/libstdc++.so.6 #13 0x003af97b in K3bCdDevice::CdDevice::init (this=0x8b739c8) at k3bdevice.cpp:219 #14 0x003ba54d in K3bCdDevice::DeviceManager::addDevice (this=0x89b5a30, devicename=@0x8b71700) at k3bdevicemanager.cpp:504 #15 0x003bd361 in K3bCdDevice::DeviceManager::readConfig (this=0x89b5a30, c=0x896c2a8) at qvaluelist.h:110 #16 0x00d79f55 in K3bCore::init (this=0x89b5b20) at k3bcore.cpp:132 #17 0x080817ba in K3bApplication::init (this=0xfefc0f40) at k3bapplication.cpp:98 #18 0x0809f388 in main (argc=0, argv=0x0) at main.cpp:120 #19 0x00751e33 in __libc_start_main () from /lib/tls/libc.so.6 #20 0x0807df61 in _start () wow... the line for this is: unsigned char* profiles = new unsigned char[len]; which version of libstdc++ do you have? $ rpm -qf /usr/lib/libstdc++.so.6 libstdc++-3.4.2-6 you may als try to $ rm -f /home/masahase/.kde/share/config/k3b* Another thing... try and start k3b with a disk inserted I think, I know what's going on... Because of bug #134822, we have bug #136155 and this bug. The inquiry does not return any value... so the "new" is called with an incredible amount of memory... Try to start k3b with a disk inserted in your SCSI drives... $ rpm -qf /usr/lib/libstdc++.so.6 libstdc++-3.4.2-6 I tryed; $ rm -f /home/masahase/.kde/share/config/k3b* And starting k3b with a disk inserted, k3b started normaly. So, this problem is solved. But this bug is not solved ,I think. kernel issue, see #134822 still causing problems with the latest errata ? 2.6.14-1.1637_FC4 has been released as an update for FC4. Please retest with this update, as a large amount of code has been changed in this release, which may have fixed your problem. Thank you. This should be fixed in current kernels. |