| Summary: | Marble widget crashes on startup most times | ||
|---|---|---|---|
| Product: | [Applications] marble | Reporter: | Adam Spiers <kde-bugs> |
| Component: | general | Assignee: | marble-bugs |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | crash | CC: | caulier.gilles, digikam-bugs-null, mklapetek, nienhueser |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 1.9.0 | |
| Sentry Crash Report: | |||
|
Description
Adam Spiers
2011-01-19 23:50:56 UTC
There are 48 (!) threads running and the application is terminated running out of memory. While that happens when Marble loads a file, I doubt the crash itself is related to Marble. I rather suspect that something else is wrong, the sheer number of running threads should be a good place to start to investigate. I think I can reproduce this fairly reliably, and am happy to help debug. I can possibly even arrange remote ssh access if that would help. By the way, since reporting, I tried compiling the SVN version of marble and rebuilding digikam against that, but it's still crashing extremely often. I also found that an rpm build of digikam 1.7.0 crashes on startup - I reported that as bug 263786. At first glance it looks like a different crash, but I don't know enough to be sure it's not a duplicate. One way to find out where all these threads come from is to run digikam under gdb and set a breakpoint at QThread's destructor. I have just committed a fix to 2.0 which prevent a good number of threads to be created at startup, though that's nothing bringing the application to its knees. With current 2.0 SVN, there are no more than about 10-15 threads created. gdb digikam br main r br QThread::QThread r for each found thread, to get a backtrace, type "bt", to continue, type "cont". If the breakpoint should be at QThread's destructor, shouldn't the line then be bt QThread::~QThread ? You're quite right ;-) I meant to write "constructor", so the debug line is right, the text not. Thanks everyone for the gdb info. I recompiled the kdegraphics/ and graphics/ trees into a common installation target with /opt/kde4 prefix (previously I had /opt/kdegraphics and /opt/digikam) and now I cannot reproduce the crashing, so I am marking this bug as INVALID. It seems a bit unlikely that the common installation target would fix the crashes, but I don't think it's worth investigating further at this point (I am going to start testing the 2.0 beta now anyway). I'll reopen if the crashes rematerialise. Thanks again! |