Summary: | Amarok sigsegv while scanning large collection | ||
---|---|---|---|
Product: | [Applications] amarok | Reporter: | Roy Dragseth <roy.dragseth> |
Component: | general | Assignee: | Amarok Developers <amarok-bugs-dist> |
Status: | RESOLVED DUPLICATE | ||
Severity: | crash | ||
Priority: | NOR | ||
Version: | 2.2.2 | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | Amarok backtrace produced with gdb. |
Description
Roy Dragseth
2010-02-16 14:51:57 UTC
What would be helpful is only the thread of the backtrace with the [KcrashHandler]. Make sure to ask gdb to thread the backtrace with 'thread apply all backtrace' once the crash happens. See also here: http://techbase.kde.org/Contribute/Bugsquad/How_to_create_useful_crash_reports#Retrieving_a_backtrace_with_GDB Created attachment 40870 [details]
Amarok backtrace produced with gdb.
The kde-crashhandler doesnt seem to kick in so I used gdb instead.
OK added backtrace, according to gdb the sigsegv seem to happen here Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffdd1ca710 (LWP 23353)] _IO_vfprintf_internal (s=0x7fffdc7cd5a0, format=0x3d95f8c6ce "%s\n", ap=0x7fffdc7cddb0) at vfprintf.c:1306 1306 f = lead_str_end = __find_specmb ((const UCHAR_T *) format); I can probably produce a valgrind backtrace too if desired. Well, your Amarok package has no debugging symbols, you should install those to get a valid backtrace, The current backtrace is not usable because of that. This might be the reason why Dr. Konqi is not showing up. You need to activate the debuginfo repository in Fedora. > https://bugs.kde.org/show_bug.cgi?id=227191
>
>
>
>
>
> --- Comment #4 from Myriam Schweingruber <myriam kde org> 2010-02-17
> 10:53:48 --- Well, your Amarok package has no debugging symbols, you
> should install those to get a valid backtrace, The current backtrace is
> not usable because of that. This might be the reason why Dr. Konqi is not
> showing up. You need to activate the debuginfo repository in Fedora.
>
That's odd, the debuginfo rpm is in place:
rpm -qa | grep amarok
amarok-2.2.2-3.fc12.x86_64
amarok-debuginfo-2.2.2-3.fc12.x86_64
amarok-libs-2.2.2-3.fc12.x86_64
amarok-utils-2.2.2-3.fc12.x86_64
r.
If you look at the start of the gdb output, it says the following: Reading symbols from /usr/bin/amarok...Reading symbols from /usr/lib/debug/usr/bin/amarok.debug... warning: section .dynbss not found in /usr/lib/debug/usr/bin/amarok.debug warning: section .gnu.liblist not found in /usr/lib/debug/usr/bin/amarok.debug warning: section .gnu.conflict not found in /usr/lib/debug/usr/bin/amarok.debug So it seems your debugging symbols are either not there, or something is wrong with the package. > https://bugs.kde.org/show_bug.cgi?id=227191 > > > > > > --- Comment #6 from Myriam Schweingruber <myriam kde org> 2010-02-17 > 11:37:40 --- If you look at the start of the gdb output, it says the > following: Reading symbols from /usr/bin/amarok...Reading symbols from > /usr/lib/debug/usr/bin/amarok.debug... > warning: section .dynbss not found in /usr/lib/debug/usr/bin/amarok.debug > warning: section .gnu.liblist not found in > /usr/lib/debug/usr/bin/amarok.debug warning: section .gnu.conflict not > found in /usr/lib/debug/usr/bin/amarok.debug > > So it seems your debugging symbols are either not there, or something is > wrong with the package. > Ok, I've asked on the fedora-kde list, but no responses so far. Just a stupid question: What more information can be expected from the backtrace if the debuginfo is included? To me the backtrace I've posted doesn't look much different than the example in the page you sent me. http://techbase.kde.org/Contribute/Bugsquad/How_to_create_useful_crash_reports#Retrieving_a_backtrace_with_GDB Best regards, r. The problem is that there is no KcrashHandler that identifies where the crash is, and with 5000 lines of output it is close to impossible to just guess > The problem is that there is no KcrashHandler that identifies where the
> crash is, and with 5000 lines of output it is close to impossible to just
> guess
OK, then I misunderstood. I got the impression from the info page that traces
produced with gdb was equally accepted as the ones produced with
kcrashhandler.
Hmm, then the question remains about why don't kcrashhandler show up. I must
admit that I haven't seen the krashhandler in a while. Earlier it used to
show up no matter if the debuginfo was installed or not.
r.
Roy, I am adding your report to one with a good backtrace. From the description and behavior this is the same bug. *** This bug has been marked as a duplicate of bug 228476 *** |