Community
Participate
Working Groups
Build ID: M20080221-1800 Steps To Reproduce: Try downloading the 32-bit Eclipse 3.3 Java Europa Winter, with a 64-bit JDK installed as the default Java, then attempt to run eclipse with. Result is a JVM error with an exit code of 13 or 14 depending on the JVM. More information: What I expect is not an indecipherable error message, rather a message that helps me understand what the real problem is.
Forgot to set severity first.
Could we detect this kind of situation in the launcher perhaps?
Please attach the error message and log. Is there any way of telling what bit the VM is before we launch it? Also are there any VM properties that are dependable for detecting the bit count of the VM?
Agree that it would be good to fix this, but it is an enhancement request.
You're calling this an enhancement when it causes the system to crash? IMNSHO, this is clearly a bug, not an enhancement request. When the system crashes and gives no clear indication of what the problem is, that's a bug. Whether you call this "correct by design" or not - it's still a bug - even if it's because the design is wrong. I expect better from Eclipse developers being a developer myself.
Kevin, do you have an error message / log file per Tom's comment 3?
Kevin, I wasn't attempting to trivialize the issue. I understand that it crashes, but you need to understand that what you want is for us to write _new_code_ to detect a _user_ error. It's equivalent to saying that it is a bug for software whose packing says "Only works on XP or newer" to crash when you run it on Windows98. It isn't. Now, it's certainly *desirable* to have the software detect that case and gracefully exit, and similarly, I'm in favor of having us enhance Eclipse to do the same in your situation. In any case, flagging a bug as "blocker" implies that you are 100% unable to continue to work until this bug is fixed. Obviously, that situation does not apply here; running either a 32 bit VM or a 64 bit Eclipse will solve your problem. I am reseting the bug to enhancement request; I hope I have convinced you that that designation is more appropriate in this case.
(In reply to comment #6) > Kevin, do you have an error message / log file per Tom's comment 3? I don't right now. If you're not able to reproduce it with my instructions in comment 0, please let me know and I'll try to reproduce it again for you. (In reply to comment #7) > Kevin, I wasn't attempting to trivialize the issue. I understand that it > crashes, but you need to understand that what you want is for us to write > _new_code_ to detect a _user_ error. I didn't know that it was environmentally dependent till immediately before I filed this bug and found my problem. I would have thought this would be a predictable user error since the decision to split 32-bit Eclipse from 64-bit Eclipse. I was surprised to learn that Java allowed for platform-dependencies in the language. That was news to me. > In any case, flagging a bug as "blocker" implies that you are 100% unable to > continue to work until this bug is fixed. Obviously, that situation does not We agree to disagree then. I see this as a blocker because there is enough room for confusion that I didn't know that running the 64-bit JVM may download the 32-bit Eclipse and not know why it doesn't work. I have to assume I'm not alone. My impression of how hard it was to get Eclipse up/running the first time was more of a nightmare than it is today, largely due to issues like this, making sure that the proper environment was paired with Eclipse, setting up the correct CLASSPATH environment variables, etc. Then, learning how to get update sites into Eclipse was also challenging until I had someone show me how to do that (changing my download / install paradigm). My goal is to make sure that adopters understand how to get the application running quickly/easily. If I had been doing Eclipse development when the decision was made to split 32-bit versus 64-bit environments, and I were reviewing the release, I would have put my foot down hard when the attempt was made to split environments without verifying that the user would always get something meaningful back if an attempt to run a mismatched JVM (JRE) with Eclipse. Perl developers have had this drilled into them with Require's.
reply to comment #8) > If I had been doing Eclipse development when the > decision was made to split 32-bit versus 64-bit environments, and I were > reviewing the release, I would have put my foot down hard when the attempt was > made to split environments without verifying that the user would always get > something meaningful back if an attempt to run a mismatched JVM (JRE) with > Eclipse. > I'm with you about the fact that we should fix this, and if I had gone through the thought process you describe, I would have argued strongly in favor of fixing it at the time, so I guess we're not actually disagreeing (except on the semantics of a field in a webform, which is fine by me <g>). Tom, have you got someone who can work on this for 3.5?
(In reply to comment #9) > Tom, have you got someone who can work on this for 3.5? > Andrew is the only committer currently available on the launcher. Only if the solution is dead simple would he be able to fit it in for 3.5. Andrew, do you think there is a simple way to detect that you are trying to launch an incompatible vm (64-bit with a 32-bit eclipse)?
We don't want to get into trying to do binary parsing to identify the vm. There are 2 cases here depending on how the vm is to be launched. (The first is native code changes, the other is java) 1) JNI launching in-process. This is fail fast, we will be unable to even load the vm shared libraries if they don't match (32 vs 64). This would currently result in eclipse exiting with -1. The thing to try here would be to see what kind of error message we can get from the os (GetLastError, dlerror). On windows this is a number, on linux it is a string. In both cases it probably would need interpreting for the user. This is a native code 2) Forking the vm in a separate process. Java will start and problems will not surface until we attempt to load a native library. SWT would likely be the first point of failure. This is not generally distinguishable from any other framework startup problem, and would generally be a return code of 13 with a message to check the log. I'm not sure where the mentioned 14 comes from. The only thing here would be to have Main check -arch against "os.arch" and fail if they don't agree. Both of these are probably more general than 32 vs 64 bits. They would likely occur on any platform mismatch. As such, in (2) we might want to also check -os vs os.name
Problem exists in 3.5 as well. I ran into the other way around - that is 32 bit JVM and a 64 bit Eclipse install. I stumbled into what was going on as it is not obvious given the lack of error message. Some error message would be preferable to no error message. At least then I'd have something to search on for help... Voting for this bug. Looks like a duplicate (or related bug) in bug#238543.
*** Bug 238543 has been marked as a duplicate of this bug. ***
*** Bug 300126 has been marked as a duplicate of this bug. ***
Moving to inbox
Created attachment 249084 [details] Some error details not able to decode it properly
*** Bug 454044 has been marked as a duplicate of this bug. ***
My machine is 64 bit and I am also facing the same problem and getting exit cod e 13.Shall I try 32 bit JDK 1.6 install and Eclipse 4.3.2 for 64 bit? Would it work?
(In reply to Diptarup Majumder from comment #18) > My machine is 64 bit and I am also facing the same problem and getting exit > cod e 13.Shall I try 32 bit JDK 1.6 install and Eclipse 4.3.2 for 64 bit? > Would it work? No. The VM bitness and Eclipse bitness must match. Since you have a 64 bit Eclipse, (from dup bug attachment) you will want to check if you have a 32 or 64 bit VM: java -version usually provides the answer.
It would be really helpful to our users if the SWT launcher could determine if the JVM is a fitting one. The launcher does this now for incorrect SWT version (see https://www.eclipse.org/eclipse/news/4.5/M4/) and it would helpful to have the same for incorrect Java runtimes.
*** Bug 455550 has been marked as a duplicate of this bug. ***
*** Bug 457271 has been marked as a duplicate of this bug. ***
An installer certainly could help to detect this - see Bug 417708 and Bug 445141
(In reply to Ralf Hauser from comment #23) > An installer certainly could help to detect this - see Bug 417708 and Bug > 445141 This bug is not about an installer but about detection at startup.
*** Bug 459705 has been marked as a duplicate of this bug. ***
*** Bug 343028 has been marked as a duplicate of this bug. ***
I really think that would be a greatfix, Dani why do you think this does not deserve this flag?
(In reply to Lars Vogel from comment #27) > I really think that would be a greatfix, Dani why do you think this does not > deserve this flag? The keyword is not here to mark worthy bugs, but to mark bugs that one signs-up for providing a fix as part of the Great Fixes form Mars program.
*** Bug 462630 has been marked as a duplicate of this bug. ***
*** Bug 463948 has been marked as a duplicate of this bug. ***
*** Bug 464534 has been marked as a duplicate of this bug. ***
*** Bug 465503 has been marked as a duplicate of this bug. ***
*** Bug 468329 has been marked as a duplicate of this bug. ***
*** Bug 472968 has been marked as a duplicate of this bug. ***
*** Bug 473302 has been marked as a duplicate of this bug. ***
*** Bug 473866 has been marked as a duplicate of this bug. ***
*** Bug 473879 has been marked as a duplicate of this bug. ***
*** Bug 475743 has been marked as a duplicate of this bug. ***
*** Bug 476094 has been marked as a duplicate of this bug. ***
*** Bug 476501 has been marked as a duplicate of this bug. ***
I suggest we add a log message that the Eclipse and JVM version must fit together. Gerrit review is coming.
New Gerrit change created: https://git.eclipse.org/r/57565
Gerrit change https://git.eclipse.org/r/57565 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=b120a79e6bbc463623cee49ee574a063e3723f75
I released the suggested log message. I also updated the launcher version for Neon.
Tried with N20151022-2000 under Linux but I also get the following message followed by the JVM arguments. Eclipse: JVM terminated. Exit code=13 Is that expected?
(In reply to Lars Vogel from comment #46) > Tried with N20151022-2000 under Linux but I also get the following message > followed by the JVM arguments. > > Eclipse: > JVM terminated. Exit code=13 > > Is that expected? My understanding is that (In reply to Lars Vogel from comment #46) > Tried with N20151022-2000 under Linux but I also get the following message > followed by the JVM arguments. > > Eclipse: > JVM terminated. Exit code=13 > > Is that expected? I would say so since the add else is in an if(!"13... So in this case the exit code will remain 13. Closing this bug as fixed. If you have concerns about the current behavior I suggest a new bug report.
*** Bug 486616 has been marked as a duplicate of this bug. ***
*** Bug 466389 has been marked as a duplicate of this bug. ***
*** Bug 461100 has been marked as a duplicate of this bug. ***
