mkisofs from app-cdr/cdrtools-2.01.01_alpha25 crashes with the following error: grsec: denied resource overstep by requesting 75799650254848 for RLIMIT_STACK against limit 8388608 for /usr/bin/mkisofs[mkisofs:266748] uid/euid:0/0 gid/egid:0/0, parent /usr/kde/3.5/bin/kcmshell[kcmshell:266718] uid/euid:0/0 gid/egid:0/0 # equery u app-cdr/cdrtools [ Searching for packages matching app-cdr/cdrtools... ] [ Colour Code : set unset ] [ Legend : Left column (U) - USE flags from make.conf ] [ : Right column (I) - USE flags packages was installed with ] [ Found these USE variables for app-cdr/cdrtools-2.01.01_alpha25 ] U I + + unicode : Adds support for Unicode
Created attachment 124846 [details] emerge --info
Reeopen with a backtrace if you can reproduce this w/ 2.01.01_alpha30; the above really won't tell us why mkisofs crashes. http://www.gentoo.org/proj/en/qa/backtraces.xml
That's a huge amount of memory! Well anyway. You're physical memory could be damaged, seriously damaged if this happens quiet often. I would suggest you to run the 'memtest86' kernel from Gentoo Minimal CD and have it run for few hours. Should it encounter any errors you'll have to get a new replacement. Yes, even a single error is serious.
Ran memtest86 for 12 hours - not a single error. Here is one stack trace generated by k3b: [?1034h(no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 49219539386480 (LWP 729344)] [KCrash handler] #5 0x00002cc3d178fb92 in K3bSetup2::updateDevices () from /usr/lib64/kde3/kcm_k3bsetup2.so #6 0x00002cc3d178ff0f in K3bSetup2::slotAddDevice () from /usr/lib64/kde3/kcm_k3bsetup2.so #7 0x00002cc3d1790b0c in K3bSetup2::qt_invoke () from /usr/lib64/kde3/kcm_k3bsetup2.so #8 0x00002cc3cec5d18c in QObject::activate_signal () from /usr/qt/3/lib64/libqt-mt.so.3 #9 0x00002cc3cec5de33 in QObject::activate_signal () from /usr/qt/3/lib64/libqt-mt.so.3 #10 0x00002cc3cec8f246 in QWidget::event () from /usr/qt/3/lib64/libqt-mt.so.3 #11 0x00002cc3cec06ac5 in QApplication::internalNotify () from /usr/qt/3/lib64/libqt-mt.so.3 #12 0x00002cc3cec078b1 in QApplication::notify () from /usr/qt/3/lib64/libqt-mt.so.3 #13 0x00002cc3cdf7fbbe in KApplication::notify () from /usr/kde/3.5/lib64/libkdecore.so.4 #14 0x00002cc3cebafb14 in QETWidget::translateMouseEvent () from /usr/qt/3/lib64/libqt-mt.so.3 #15 0x00002cc3cebaec31 in QApplication::x11ProcessEvent () from /usr/qt/3/lib64/libqt-mt.so.3 #16 0x00002cc3cebbda0f in QEventLoop::processEvents () from /usr/qt/3/lib64/libqt-mt.so.3 #17 0x00002cc3cec1b2a2 in QEventLoop::enterLoop () from /usr/qt/3/lib64/libqt-mt.so.3 #18 0x00002cc3cedb83bb in QDialog::exec () from /usr/qt/3/lib64/libqt-mt.so.3 #19 0x00002cc3cd055d60 in kdemain () from /usr/kde/3.5/lib64/libkdeinit_kcmshell.so #20 0x00002cc3d105b374 in __libc_start_main () from /lib/libc.so.6 #21 0x0000000000400789 in ?? () #22 0x00007bb08a60ad78 in ?? () #23 0x0000000000000000 in ?? () By the way, k3bSetup screwed up my hda cdrom so it is not accessible anymore. Should I open it as a separate bug or should it be a part of this one?
(In reply to comment #4) I meant a backtrace from mkisofs, not from running k3bsetup. > By the way, k3bSetup screwed up my hda cdrom so it is not accessible anymore. You shouldn't use k3bsetup, no need for that (plus udevcontrol reload_rules or reboot will restore the permissions)
How can I get a trace from mkisofs? It is launched from K3b - so I don't know the exact command being executed. And when I start K3b from gdb, it detaches mkisofs from the debugger. Could you give a suggestion? Thank you
Doesn't go anywhere. If you can reproduce w/ >=2.01.01_alpha34 and k3b-1.0.4 using sane permissions (not mangled by k3bsetup which no longer is installed by the ebuild anyway), then attach the requested into and reopen the bug. http://www.gentoo.org/proj/en/qa/backtraces.xml
