Summary: | Kicker crashes on startup. | ||
---|---|---|---|
Product: | [Unmaintained] kicker | Reporter: | Dylan Griffiths <dylang> |
Component: | general | Assignee: | Aaron J. Seigo <aseigo> |
Status: | RESOLVED DUPLICATE | ||
Severity: | crash | ||
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Slackware | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
Kicker strace of its crash.
The config file that caused the crashes. |
Description
Dylan Griffiths
2004-10-24 20:08:00 UTC
Created attachment 8017 [details]
Kicker strace of its crash.
Here is the strace listing of kicker's death throes. It looks like some
communication problem occurs, making it crash. I've tried (via kcontrol) to
delete and reset the panels (since I have a main panel and 2 child panels; 1
for each Xinerama monitor), but KDE doesn't seem to be smart enough to
self-repair bad values (bad design! :() or allow reseting panels without the
kicker actually running and providing an implementation of a config dialog.
Created attachment 8018 [details]
The config file that caused the crashes.
Here's the config file that caused the crashes. By renaming this and running
Kicker again, I triggered another kicker crash, but this time it "healed"
itself and actually started a fresh kicker with a default config.
Perhaps you can figure out what code path is not handling an error condition
correctly and fix it.
first, thanks for the thoroughness. i do appreciate that as the person who gets to deal with these things. now for the bad news ;-) the crash was actually due to the WorldWatch applet on one of the childpanels. when this happens after an upgrade it's usually because that applet didn't get updated properly. there is, really, nothing that kicker can do about applets that are "trusted" that crash. that said, the strace you attach is KUniqueApplication fork'ing and pinging via dcop the actual process. it isn't the crashing application however (which had previously been fork()'d) and the config file included isn't the one causing the problem. it would be the childpanel config. as for switching from Xinerama to non-Xinerama, i've actually Q/A'd _exactly_ that (with 2 screens and four panels down to a non-Xinerama X set up) and it works just fine. but then, that wasn't where the bug was =) as for the "other kicker crash" that occured when you mv'd kickerrc, did you happen to grab a backtrace for that? is it reproducable? if you add the WorldWatch applet back to the panel, do you experience further crashes? if so, can you provide a backtrace? loading it via appletproxy from the command line is the easiest way to get a good backtrace on an applet. also, did you update the kdetoys package when upgrading? The above backtrace looks similar to one I recently fixed in HEAD and BRANCH. Should be in 3.3.2 "if you add the WorldWatch applet back to the panel, do you experience further crashes? if so, can you provide a backtrace? loading it via appletproxy from the command line is the easiest way to get a good backtrace on an applet. also, did you update the kdetoys package when upgrading?" I did upgrade the KDE toys package. All KDE stuff is 3.3.1 from Slackware -current as of Oct 23rd. Loading the WorldWatch applet nets me a nice empty space on the kicker panel with a handle, but no rendered client data. I don't know what's going on there :-/ Why are child applets trusted? Wouldn't it be possible to design kicker such that no child applets could crash kicker? ok, so the WorldWatch applet is broken. that's the problem here. if you wish to find out more information run `appletproxy kwwapplet` from a konsole window. > Why are child applets trusted? lower overhead and easier management... > Wouldn't it be possible to design kicker such that no child applets could > crash kicker? yes, we could run every applet in the appletproxy at all times. i'll seriously consider this. for now, can you try running the wwapplet through appletproxy and let me know what it says? thanks =) dylang@shadowgate:~$ appletproxy kwwapplet FAILURE (KCmdLineArgs): Application requests for isSet("theme") but the "theme" option has never been specified via addCmdLineOptions( ... ) dylang@shadowgate:~$ echo $? 255 I really do not know anything about the internal design of the applet framework or kicker; I've only programmed Gnome panel applets, and then only a few years back as a lark (because C is fun to debug, especially when the stupid Gnome interfaces are not document :))... As mentioned before, the worldwatch applet is fixed. Was bug #88802. Dylan, any news from that other crash without config file? Maybe this should go into a new bug report if you can reproduce it. So this one can be closed, I think. *** This bug has been marked as a duplicate of 88802 *** |