Summary: | app-cdr/k3b-2.0.2-r1 crash on start (hardened, sigsegv) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alex Efros <powerman-asdf> |
Component: | [OLD] KDE | Assignee: | Gentoo KDE team <kde> |
Status: | RESOLVED NEEDINFO | ||
Severity: | normal | CC: | hardened, media-optical |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Alex Efros
2011-03-22 00:29:00 UTC
I've tried to improve backtrace using this: - added "-O1" and "-ggdb" to CFLAGS and CXXFLAGS - added "nostrip" to FEATURES - added USE-flag "debug" - re-emerged k3b This make backtrace better, but still doesn't detailed enough. Maybe some other libraries should be re-emerged with these settings too? Application: K3b (k3b), signal: Segmentation fault [KCrash Handler] #6 0xaf78313b in ?? () from /lib/ld-linux.so.2 #7 0xaf7837fa in ?? () from /lib/ld-linux.so.2 #8 0xaf7899a0 in ?? () from /lib/ld-linux.so.2 #9 0xaf78a2e6 in ?? () from /lib/ld-linux.so.2 #10 0xaf788c8a in ?? () from /lib/ld-linux.so.2 #11 0xaf78e6d1 in ?? () from /lib/ld-linux.so.2 #12 0xaf78a2e6 in ?? () from /lib/ld-linux.so.2 #13 0xaf78e0e6 in ?? () from /lib/ld-linux.so.2 #14 0xac4f9c1b in ?? () from /lib/libdl.so.2 #15 0xaf78a2e6 in ?? () from /lib/ld-linux.so.2 #16 0xac4fa0ac in ?? () from /lib/libdl.so.2 #17 0xac4f9b51 in dlopen () from /lib/libdl.so.2 #18 0xad5664aa in ?? () from /usr/lib/qt4/libQtCore.so.4 #19 0xad56031e in ?? () from /usr/lib/qt4/libQtCore.so.4 #20 0xad560674 in ?? () from /usr/lib/qt4/libQtCore.so.4 #21 0xad5598bd in QPluginLoader::load() () from /usr/lib/qt4/libQtCore.so.4 #22 0xad8b3407 in KPluginLoader::load() () from /usr/lib/libkdecore.so.5 #23 0xad8b466d in KPluginLoader::KPluginLoader(KService const&, KComponentData const&, QObject*) () from /usr/lib/libkdecore.so.5 #24 0xaf633ce2 in KService::createInstance<K3b::Plugin> (this=0x1a8edd28, parentWidget=0x0, parent=0x1a8f0df0, args=..., error=0x0) at /usr/include/kservice.h:514 #25 0xaf633ec6 in KService::createInstance<K3b::Plugin> (this=0x1a8edd28, parent=0x1a8f0df0, args=..., error=0x0) at /usr/include/kservice.h:494 #26 0xaf6322ae in K3b::PluginManager::Private::loadPlugin (this=0x1a8f0db0, service=...) at /var/tmp/portage/app-cdr/k3b-2.0.2-r1/work/k3b-2.0.2/libk3b/plugin/k3bpluginmanager.cpp:102 #27 0xaf6325ac in K3b::PluginManager::loadAll (this=0x1a8f0df0) at /var/tmp/portage/app-cdr/k3b-2.0.2-r1/work/k3b-2.0.2/libk3b/plugin/k3bpluginmanager.cpp:158 #28 0xaf5d33cd in K3b::Core::init (this=0x1a8e8098) at /var/tmp/portage/app-cdr/k3b-2.0.2-r1/work/k3b-2.0.2/libk3b/core/k3bcore.cpp:196 #29 0x1a782593 in K3b::Application::Core::init (this=0x1a8e8098) at /var/tmp/portage/app-cdr/k3b-2.0.2-r1/work/k3b-2.0.2/src/k3bapplication.cpp:317 #30 0x1a783580 in K3b::Application::init (this=0xbf629b24) at /var/tmp/portage/app-cdr/k3b-2.0.2-r1/work/k3b-2.0.2/src/k3bapplication.cpp:116 #31 0x1a78384d in K3b::Application::qt_metacall (this=0xbf629b24, _c=QMetaObject::InvokeMetaMethod, _id=2, _a=0xbf6291c8) at /var/tmp/portage/app-cdr/k3b-2.0.2-r1/work/k3b-2.0.2_build/src/k3bapplication.moc:80 #32 0xad57c141 in QMetaObject::metacall(QObject*, QMetaObject::Call, int, void**) () from /usr/lib/qt4/libQtCore.so.4 #33 0xad58c22c in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/qt4/libQtCore.so.4 #34 0xad594189 in ?? () from /usr/lib/qt4/libQtCore.so.4 #35 0xad5942cc in ?? () from /usr/lib/qt4/libQtCore.so.4 #36 0xad588860 in QObject::event(QEvent*) () from /usr/lib/qt4/libQtCore.so.4 #37 0xaca67002 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/qt4/libQtGui.so.4 #38 0xaca6dc2a in QApplication::notify(QObject*, QEvent*) () from /usr/lib/qt4/libQtGui.so.4 #39 0xadb3a372 in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdeui.so.5 #40 0xad576822 in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/qt4/libQtCore.so.4 #41 0xad5a9098 in ?? () from /usr/lib/qt4/libQtCore.so.4 #42 0xad5a589e in ?? () from /usr/lib/qt4/libQtCore.so.4 #43 0xabaa40d0 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #44 0xabaa8101 in ?? () from /usr/lib/libglib-2.0.so.0 #45 0xabaa82d1 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #46 0xad5a54e5 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/qt4/libQtCore.so.4 #47 0xacb30f87 in ?? () from /usr/lib/qt4/libQtGui.so.4 #48 0xad574ab4 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/qt4/libQtCore.so.4 #49 0xad574f9d in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/qt4/libQtCore.so.4 #50 0xad57a785 in QCoreApplication::exec() () from /usr/lib/qt4/libQtCore.so.4 #51 0xaca670a3 in QApplication::exec() () from /usr/lib/qt4/libQtGui.so.4 #52 0x1a7a3741 in main (argc=1, argv=0xbf629ec4) at /var/tmp/portage/app-cdr/k3b-2.0.2-r1/work/k3b-2.0.2/src/main.cpp:151 Please report this upstream at bugs.kde.org and add here a link to that bug report. Actually this segfault can be fixed simply with: paxctl -m /usr/bin/k3b so please add paxmarking into ebuild. Real issue is PaX become less verbose in latest versions. Previously all segfaults which happens because of hardened was ease to detect by looking in kernel logs. But this segfault doesn't listed in kernel log at all, so it's harder to find out it happens because of PaX. (In reply to comment #3) > Actually this segfault can be fixed simply with: > paxctl -m /usr/bin/k3b > so please add paxmarking into ebuild. > > Real issue is PaX become less verbose in latest versions. Previously all > segfaults which happens because of hardened was ease to detect by looking in > kernel logs. But this segfault doesn't listed in kernel log at all, so it's > harder to find out it happens because of PaX. @hardened: what's to do here? if you think adding pax-mark in the ebuild makes sense, please just go ahead... Did the pax or grsec log show anything? It start fine for me. Do strace show anything? Portage 2.1.10.36 (hardened/linux/amd64, gcc-4.6.2, glibc-2.12.2-r0, 3.0.4-hardened-r5 x86_64) ================================================================= System uname: Linux-3.0.4-hardened-r5-x86_64-Intel-R-_Core-TM-_i7_CPU_Q_720_@_1.60GHz-with-gentoo-2.1 Timestamp of tree: Sat, 19 Nov 2011 12:45:01 +0000 app-shells/bash: 4.2_p10 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.6.7-r2, 2.7.2-r3, 3.1.4-r3, 3.2.2 dev-util/cmake: 2.8.6-r1 dev-util/pkgconfig: 0.26 sys-apps/baselayout: 2.1 sys-apps/openrc: 0.9.4 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.68 sys-devel/automake: 1.8.5-r4, 1.9.6-r3, 1.11.1-r1 sys-devel/binutils: 2.21.1-r1 sys-devel/gcc: 4.4.4-r2, 4.5.3-r1, 4.6.2 sys-devel/gcc-config: 1.5-r1 sys-devel/libtool: 2.4-r3 sys-devel/make: 3.82-r3 sys-kernel/linux-headers: 2.6.39 (virtual/os-headers) sys-libs/glibc: 2.12.2 (In reply to comment #4) > (In reply to comment #3) > > Actually this segfault can be fixed simply with: > > paxctl -m /usr/bin/k3b > > so please add paxmarking into ebuild. > > > > Real issue is PaX become less verbose in latest versions. Previously all > > segfaults which happens because of hardened was ease to detect by looking in > > kernel logs. But this segfault doesn't listed in kernel log at all, so it's > > harder to find out it happens because of PaX. > > @hardened: what's to do here? if you think adding pax-mark in the ebuild makes > sense, please just go ahead... Having an "emerge --info k3b" would be very helpful, I think your culprit is ffmpeg ;) Zorry it is an x86 system > Having an "emerge --info k3b" would be very helpful, I think your culprit is
> ffmpeg ;)
>
> Zorry it is an x86 system
|