Qt4 apps spontaneously refuse to launch.
Page 1 of 1 (11 posts)
Tags:
None
Registered Member 
|
Hi All,
Firstly, I should mention that I'm actually running the Trinity Desktop Environment [1], but since my problem is regards Qt4 Apps exclusively, I was hoping that I might find some advice here. The problem I am having is, that some time during a session (I haven't isolated a trigger yet, but it may be a simple as opening/closing qt4 apps), launching of Qt4 apps will no longer work. To be precise, the apps don't so much crash, as appear to function without the Qt4 UI. I've only tried a handle full of apps, (Qjoypad, VLC, etc), but the most notable is VLC which seems to fall back to an ASCII renderer, yet all keyboard shortcuts, etc appear to continue functioning as expected. I can find the processes of other apps running with "ps", and close them with a SIGTERM. Here is output If I try to launch vlc from a terminal after the problem has been triggered:
I get none of this save the first 2 lines when doing the same before the problem occurs. What I'm looking for is any advice of where I might look for more clues or information, such as environmental variable, lock files, services, etc relating to Qt4 which might shed some light on situation. Some more points of interest: - This only effects newly launched apps. All qt4 apps already running continue to function normally. - The problem is reset when the computer is restarted. - It only effects the current user/session. Launching another session (i.e. so two sessions are running simultaneously), the problem is not exhibited in this new session. Thank you. - Andreas [1] http://www.trinitydesktop.org/ |
Administrator
|
Sounds like there may be some library being inserted via LD_PRELOAD or is being added into LD_LIBRARY_PATH which is causing a symbol conflict.
Unfortunately VLC's use of Qt is through a plugin, so it won't generate the appropriate complaint. Could you try using a Qt 4 only application (such as a KDE 4 KWrite or similar).
KDE Sysadmin
[img]content/bcooksley_sig.png[/img] |
|
Registered Member
|
Hi bcooksley,
Thanks for your reply. It doesn't look like I've got LD_PRELOAD or LD_LIBRARY_PATH set according to printenv (could this be the problem?). I Installed Kwrite and seemed to get largely the same output:
Thanks again for your help. - Andreas |
|
Administrator
|
Hmm. Do you get similar output when everything is working properly?
It almost looks like your system has run out of graphics memory, or something else is breaking in X based on that output (which is highly unusual).
KDE Sysadmin
[img]content/bcooksley_sig.png[/img] |
|
Registered Member
|
No, only afterwards. ...Although I do now (having restarted and hence reset the problem) get this message which I don't remember seeing before...
Looks like just some disparity in a config file, and I did just do a system update, so I would presume that to be the cause...
It does seem that way. I doubt it's video memory as I still manage to play games just fine, and this does only seems to effect Qt4 apps, but the same errors crop up in .xsession-errors as well, so the error messages are at least from X. Unfortunately this doesn't tell us if the errors are generated by X because Qt has does something wrong, or reflecting something X has done wrong to upset Qt. Thanks again for your help. |
|
Administrator
|
This message is probably the most telling as to why the problem begins:
Does an application or command you run alter the configuration of your display, such as lowering the number of available colours or similar? I suspect that something you are using (such as a game or some other application which probably goes full screen) is altering the screen display properties and not setting them back to normal. This causes the launch of Qt applications to fail. You could try running Qt applications using the "--visual TrueColor" or "--cmap" arguments when it glitches again - as this may possibly work around the issue.
KDE Sysadmin
[img]content/bcooksley_sig.png[/img] |
|
Registered Member
|
Ah, it looks like that was it! Appending either "--visual TrueColor" or "--cmap" to any KDE4 app allows it to run. Unfortunately, I have not yet come up with a work-around for apps that use Qt4 as a plugin (such as VLC).
I do run quite a few games full-screen, as well as a few other strange things that may affect the screen, but so far I still have not been able to isolate the cause. Now, as far as I can see, it's not actually possible to change the color-depth of an X-session already in progress, and it would appear to have been started with a depth of 24bits:
"--cmap" works by installing a private color-map according to the man pages (I don't know about "--visual TrueColor"), so I'm wondering if the problem is with color-maps. According to some X documentation, management of color-maps is generally handled by the window manager, which could also explain why no one with KDE4 has apparently had this problem. I'll keep having a dig around and see if I can find any more information. |
|
Administrator
|
It would certainly be interesting to find out what causes this. If the window manager does indeed manage the colour maps, then it should work - although the Trinity modifications to KWin could possibly have broken that behaviour (assuming KWin managed colour maps at all in it's KDE 3 codebase).
KDE Sysadmin
[img]content/bcooksley_sig.png[/img] |
|
Registered Member
|
Well, it's been several weeks now and I'm no longer able to trigger the problem any more. I've certainly been trying. I've tried everything I had previously suspected, as well as starting applications I know do strange things with color-maps, and then making them crash.
In the off chance that someone else starts experiencing the same problem, here is what I would have tried next: "xstdcmap" is a command line program contained in the "x11-xserver-utils" package (at least on ubuntu) which can be used to manipulate color-map definitions. I was hoping that I may be able to somehow use this as a workaround once the problem triggers. I was also considering hacking together a QT4 application to try and acquire some more information. http://doc.qt.digia.com/qt/qx11info.html Contains information on some X related functions (including some access to color-maps). I'll post again if I can find out anything new, but it looks like that may be a while. |
|
Administrator
|
I'll mark this as solved for now as it seems that the issue has gone away.
KDE Sysadmin
[img]content/bcooksley_sig.png[/img] |
|
Registered Member
|
Just a quick note to say that the problem finally reoccurred. I've found the cause, and a successful work-around.
The Cause: Apparently, is was virtualbox. I should have realised this when I noticed it was the only Qt4 based application that still worked after this bug was triggered. This doesn't happen all the time, so it may be something strange in my configuration, etc which is triggering this. The Fix: It would seem that virtualbox either installs a colormap that only it can use, or in some other way corrupts my system's colormap setup. The following reverts the system to a good state:
"xstdcmap" is a command line program contained in the "x11-xserver-utils" package (ubuntu). Thank you again for all your help bcooksley. |
Page 1 of 1 (11 posts)
Bookmarks
Who is online
Registered users: abc72656, Bing [Bot], daret, Google [Bot], lockheed, Sogou [Bot], Yahoo [Bot]
