Community
Participate
Working Groups
Created attachment 254283 [details] Screenshot showing an X icon instead of the usual debug icon. When working in Eclipse 4.5RC4 for a while, the debug icon changes to some "other" icon. In a new session the icon is correct. After a while, when using the debug perspective, the icon changes to the one used for "Terminate", "Remove termindated", "Disable all breakpoits", etc. These are the ones I have seen so far, in the few days I've been using 4.5RC4. The perspective button works fine otherwise.
Cool. As if the perspective icon would "steal" the debug toolbar icons. Any related errors in the log? Is only debug perspective icon affected? Any idea what can cause the change (perspective switch etc)? Changes the icon back to the default one? What happens if you close/reopen the perspective?
Meanwhile another icon decided to shapeshift (the Script Explorer "back" icon, see attachement). Changed bug summary to reflect the problem is not specific to the debug icon. Will check my error log and report back. I also changed the severity to "critical" now, if lots of icons start to show the incorrect pictogram after a few hours in an eclipse session, and restarting is the only remedy, this can become very tedious, and should be fixed in 4.5.0 Mars or at least in 4.5.1 Mars SR1, don't you think? I've only spotted 2 occurances (my debug icon changed again, and the incorrect "back" icon is new) of the problem within a 6 hour session, but I wasn't very active in terms of switching perspectives or using lots of different views. It might become worse for other users quickly.
Created attachment 254294 [details] Screenshot showing incorrect pictogram for script-exporer ~ back button.
Created attachment 254295 [details] Screenshot showing yet another icon instead of the usual debug icon. Screenshot from same eclipse session as attachement 254283, now showing another icon. Thus, it appears as if there was either a changing icon list or cache being refered to with the correct index, or a variable index referring to a static icon list. Or both of these. ;)
(In reply to Andrey Loskutov from comment #1) > Any related errors in the log? No, the log is clean (besides two kinds of errors I know well and are unrelated). > Is only debug perspective icon affected? See my previous comment, over time it seems other icons get affected, too. I did see the debug icon get funky in two different sessions though, so this might be a good start trying to reproduce the problem. > Any idea what can cause the change (perspective switch etc)? Not really, I didn't see any specific action that caused it. I did open more perspectives during the session, and reordered them, so this might be worth playing with. > Changes the icon back to the default one? Meanwhile I also had a strange maximize icon, that vanished again when I maxized the window by double clicking it's tab, and then restored it. Also, the back icon in script explorer came back normal when the view was closed and restarted. Thus it seems that reinitializing the affected UI object resets the incorrect state. > What happens if you close/reopen the perspective? It (re)opens with the correct icon. Merely switching perspectives does not help.
Of it possible that the hdpi support for images is causing these strange thing?
Created attachment 254296 [details] Strange maximize icon Another example, for the sake of completeness. It appears to be not limited to any kind of UI widget, looks like it can appear on "anything" with an icon. I think I've seen the X instead of the normal maximize icon before 4.5RC4, when more editors than fit in the header are open, and the downward chevron icon appears. Maximizing/minimizing any window will help. The workspace I am working with was created with 4.5RC3, BTW, so it's relatively fresh.
(In reply to Andrey Loskutov from comment #1) > Cool. As if the perspective icon would "steal" the debug toolbar icons. Now that you mention it. It actually appeared like that. First it was the X (remove) then the red box (terminate) and in the end the maximize window symbol. Thinking of it, the last screenshot I made actually co-incided with that. The script explorer maximize button got the X that was previously on my debug perpective icon, while that one got the actual maximize symbol. It might be totally random rather than coincidential, I didn't see if these swaps actually happend at the same time, but the plot thickens. ;)
I highly doubt that Platform ui is responsible to this smells like swt is mixing up native handels
(In reply to Thomas Schindl from comment #6) > Of it possible that the hdpi support for images is causing these strange > thing? Nope. I've never seen this so far. Could also be that the machine goes out of handles.
(In reply to Dani Megert from comment #10) > I've never seen this so far. I also do not see that on my Linux machine.
Reducing importance to "minor". When I had this error frequently, I had multiple instances of Eclipse running, the machine was stressed (high CPU load, low memory / lots of paging), so maybe there were also some (I/O) timeouts involved, like populating or updating icon caches, maybe. I didn't see the problem in a while, but I since am on a more normal scenario, too. I didn't really tie the ability to reproduce this to machine load at first. Since I didn't see the problem under moderate load, I wonder if it's not actually just a GDI/WPF problem I managed to summon... Thus, if anyone has seen this behaviour, please confirm. Otherwise, I'm fine with this bug being closed without action.
(In reply to Alexander Wessel from comment #12) > Reducing importance to "minor". > Thus, if anyone has seen this behaviour, please confirm. Otherwise, I'm fine > with this bug being closed without action. Thanks for the feedback.
Just as a hint should this re-occur again, and end up reopened: One other reason for this to happen might be that out of memory-exceptions, I/O exceptions or other vm exceptions could be caught where they shouldn't, e. g. during updates of UI elements / icon caches, by some catch(Throwable t) or the like. That would explain why I've seen this under heavy CPU/memory stress, but never without. The exception might terminate the UI worker / thread, but if caught and not treated or rethrown might not kill the application altogether, but leave the UI in an incorrect/inconsistent state. Maybe someone with a good understanding of the code that might be involved wants to overlook it for possible occurances of such error patterns. It's where I'd start...
