Summary: | Marble widget crash on start | ||
---|---|---|---|
Product: | [Applications] marble | Reporter: | miki <vmikiv> |
Component: | general | Assignee: | Torsten Rahn <rahn> |
Status: | RESOLVED DUPLICATE | ||
Severity: | crash | CC: | caulier.gilles, cfeck, mpyne, nienhueser, rahn |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Unlisted Binaries | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
miki
2009-05-31 14:10:55 UTC
Another XIOError. I hate KGLOBAL_STATIC destructors called for XIO errors, because people would think the bug is elsewhere. See also my comment in bug 178844. Christoph: So where do you suggest that the bug is? miki: Does it crash reproducably on every startup? If so, are you using Marble 0.8SVN together with normal digikam packages or have you recompiled digikam in order to work well with Marble? Any digikam packages that were made against KDE 4.2 will only work well with Marble 0.7.x. The bug is either in Qt or in X11. Look at frame entry #9, that error causes the application to exit(). Many classes, however, are not prepared that static destructors are called without the proper cleanup from QObject first. Also, the order those destructors are called is not changable. There should be a way to exit a process without calling static destructors, I know that AmigaOS had both an exit() and an immediate _exit() entry, not sure about POSIX... (In reply to comment #3) > The bug is either in Qt or in X11. Look at frame entry #9, that error causes > the application to exit(). This is not the cause, but just a consequence. The real problem is thread #1 crashing, most probably trying to delete some invalid memory (double deletion or uninitialized memory); thread #1 (with the X event handling) goes bersek just because of that. still crash with last trunk r-977494 Ok, if thread #1 is the culprit then why did this bug get assigned to Marble? By looking at the classes involved with thread 1 I'd rather say that this is a digikam bug ... It seems to me that the crash was from Thread 2 (where [KCrash Handler] is seen. This correlates well with mem2chunk_check() catching some kind of memory corruption. Marble::PlacemarkLoader::loadFile() was running in this thread right before the crash, which I suppose is why the crash was assigned to Marble. Looks like the same problem as https://bugs.kde.org/show_bug.cgi?id=218873#c8 Please reopen if it is still happening. *** This bug has been marked as a duplicate of bug 218873 *** |