Red Hat Bugzilla – Bug 439543
kstars live-locks just after startup
Last modified: 2009-06-07 19:17:51 EDT
Description of problem:
kstars live-locks just after startup. Sometimes tips dialog does not star,
other times I can get in enough to set the time but it locks up after the dialog
finishes (setting the time to be displayed).
Live-lock: freezes with 100% cpu usage.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.launch kstars from menu or gnome terminal
Program within a couple of seconds of startup.
What X hardware/driver are you using?
running in GDB, a ^C gives:
0x0222c271 in QDashStroker::processCurrentSubpath () from /usr/lib/libQtGui.so.4
00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express
Processor to DRAM Controller (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML
Express Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express
Graphics Controller (rev 03)
What's the easier way of determining X drivers being used?
grep Driver /etc/X11/xorg.conf, make sure you're not running vesa?
Also try strace or oprofile to gather info about where that cpu time is going.
(I can't run it so I cannot see whether it works for me, no 3d support at the
fwiw, I cannot reproduce, works great here. I almost always use kstars when
demo'ing kde4. :)
Created attachment 302386 [details]
strace of kstars (2.78 MB)
There's a long list of "Resource temporarily unavailable" just before it locks
xine (from livna) gives me the same error, although it doesn't lockup, just no
video (audio only).
Looka like an X11 authentication problem: the first EAGAIN is a write to the
X11 socket (@/tmp/.X11-unix/X0). That's during or shortly after authentication,
so I guess X11 doesn't like the authentication cookie.
For Comment #4:
grep Driver /etc/X11/xorg.conf
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
I have the same problem with kstars. The "Setup Wizard" comes up every time I
start kstars even though, just before it hangs, I can see my selected location
in the bottom left-hand corner of the main window.
Is this still an issue with KDE4 4.0.5? If so you may wish to file an upstream
bug report at http://bugs.kde.org then add the upstream info to this report.
We will monitor upstream for a resolution
I also notice kstars crashes on two machines, 500MHz PIII laptop and 2,4GHz
Athlon both using KDE. If I do nothig, the program can work longer but if I try
to do something, zoom, move, or search anything, the crash is almost shure.
My kdeedu is the last update.
Thanks for the report. I checked upstream and could not find a matching bug.Please file a bug report in the the upstream bugzilla located at http://bugs.kde.org for the particular component involved.
Once you've filed your bug report to the upstream bugzilla, please add the upstream info to this report. We will continue to track the issue in the centralized upstream bug tracker, and will review any bug fixes that become available for consideration in future updates.
Setting status to NEEDINFO, and awaiting upstream bug report URL for tracking.
Thanks in advance.
Wojciech, your issue is something separate (crash vs lockup).
In the meantime, is this still reproducible with latest updates (kdeedu-4.1.3)?
Is this still an issue with 4.1.4 if so please report upstream.
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution.
Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information.
Closing as INSUFFICIENT_DATA.
Steven M. Parrish - KDE Triage Master
Fedora Bugzappers volunteer triage team