Division by zero in org.eclipse.swt.program.Program.getImageData #193
Comments
|
This is a regression from eclipse-platform/eclipse.platform.swt#409. The reason will probably be that @nikita-leontiev To identify potential other reasons than the OS version, can you give some information about your monitor setup? Do you use multiple monitors, probably with different scaling settings? |
|
@deepika-u Can you please take a look? |
|
I have one monitor. |
|
Since Windows 7 is EOL and I have already seen other places in SWT code where Windows-7-specifics have been removed, I am not sure whether this can/should be addressed. |
|
Then it should throw |
Agreed. That needs to be fixed where the problem is caused, i.e., in |
|
Just instead of completely remove and lock out users, one can probably just assume a Zoom level of |
|
On the one hand, it is easy to solve the issue for user of outdated environments with that proposal. On the other hand, it will make it more difficult to find regressions because of having some fallback logic that always applies and not only in the cases it is supposed to be used for (outdated OS). So to implement that fallback "properly", we would need to apply it only when it is accepted to have zoom value of "0", which is kind of equivalent to partly reverting eclipse-platform/eclipse.platform.swt#370 and introducing Windows 7/8-specific functionality. I think there are good arguments for both. My (rather personal) opinion is that we should not invest (and risk undetected regressions) because of supporting EOL operating systems in any way. I would even be in favor of adding a validation for outdated OS on startup and requiring users to specify some flag if they want to start the application on an operating system that is not supported on the framework anymore,so make it very explicit that the application can fail because of an unsupported environment. |
|
Given that the Deutsche Bahn is approaching for a Windows 3.11 Adminstrator it seems a bit harsh for me to simply cut of Windows 7 / 8 users with just the gain to save a zero check :-) Maybe one can emit a warning in case to find regressions, but the risk (complete failure) seems rather high even in that case compared to a degraded functionality (e.g. incorrect zoom value). |
|
Sorry for moving to such a "general" discussion, probably that's better placed somewhere else. In particular, that is not about saving a zero check, but about the general question whether code should be written to support environments that are actually unsupported. It is rather about expectation management: there seem to be people expecting recent Eclipse/SWT to properly run on an outdated system. If some company decides to run EOL environments that is fine, but then they should not expect newest Eclipse/SWT to run on them. For this particular issue, it would be fine for me to have that fallback, maybe combined with some warning to find regressions. Still I would like to have that general discussion about expectation management at some other placeand maybe the option to only run on unsupported systems by explicitly adding some flag. |
|
Yes this is a quite wider topic, but it does not only affect Eclipse (as an IDE) but any SWT based products, so these products will obviously get the complains from the users even though they often can't control it. So if it is possible to at least use SWT for example with degraded function (say zoom not working properly) is maybe better than consist of an EOL of a product (what somehow is a management decision) users are not always in control, so if it is just that Zoom adjustments no longer work reliable, then that would defiantly be something we should try to retain. Adding all kinds of flags on the other side seem not very valuable to me, the "flag" is already running on Windows < 11 so maybe that's more of an option to find out what windows version is used and the see if there are people that maintan these codepath or not. |
|
SWT is so low on people working on it that efforts to support "unsupported" OSes by their own producers is just time lost. |
Exactly, it affects every product based on SWT as a library. But I disagree with the implication of the statement about products getting complains from user. If you base your product on some library or framework and a new version of the library/framework changes its requirements, you as a product provider have to decide whether you want to use the new version of it and adapt the system requirements of your product accordingly or whether you want to stick to an older version to have rather "relaxed" requirements. I do not see anything special for SWT here, expect for not having an explicit definition of the system requirements for using SWT (which is basically what I would propose to add).
Let me phrase the proposal differently:
Coming back to this issue: If there are complains about removing support for Windows 7/8 (in this special case), I'd propose to submit a PR revert the according commit: eclipse-platform/eclipse.platform.swt@3cc6898 |
|
👍 I reduce my proposal to having on Windows what already exists for Linux/GTK 🙂 |
|
Hello everyone. |
|
For what it's worth, perhaps you can successfully roll back to the previous installation profile from before the update:
You can also disable automatic updates to avoid them:
|
|
@merks It is clear, thank you. Now i know from this thread that i need to do it. |
|
Win7 user here. Thank you for acknowledging and discussing the bug in detail. I believe you should not drop support for OSes in this way. The fact is that Eclipse still works fine other than this breaking bug. As long as "support" means "handle strange values gracefully with a single line of code", I do not see the problem. Once "support" means "rewrite this whole feature", just don't enable that feature on outdated OSes. Don't confuse those 2 situations please. And, under no circumstances, should you ship updates to users that will BREAK an existing installation. That is just rude. Just leave us on an older version of Eclipse if you have to. How should I, a mere user, know that I should not have updated? After all, Eclipse is very insistent on this ("the installation does not satisfy the criteria blablabla" on every start). (now I have to figure out how to roll back - Eclipse is not very easy to use in that regard in my experience so far) |
Let's make sure issue is not already fixed in latest builds first.
Steps to reproduce
From a fresh installation and clean workspace:
I expected: no exception.
But got: exception occurred.
Here is some relevant log output
From
<workspace>/.metadata/.logTested under this environment:
Community
The text was updated successfully, but these errors were encountered: