Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

jline on Windows does not check that %TEMP%\jansi.dll is correct for JVM bit model #4703

Closed
scabug opened this issue Jun 16, 2011 · 10 comments
Closed
Assignees
Labels
Milestone

Comments

@scabug
Copy link

scabug commented Jun 16, 2011

There are two jansi.dll bundled in jline.jar, one for 32 bits and one for 64 bits. The one being picked up is chosen based on the value of sun.arch.data.model system property (32 or 64). Once unpacked the dll does not get refreshed. The only check that is performed is based on timestamp of jline.jar and jansi.dll. Running first the 32 bits version unpacks the 32 bits dll. When starting the 64 bits JVM, jansi.dll is then incompatible. (or vice versa if starting with 64 bits).

The bug is really in the hawtjni dependent library used by jline.

Here is a cygwin session demonstrating the issue:

$ rm /cygdrive/c/Users/jlh/AppData/Local/Temp/jansi.dll

$ scala
Welcome to Scala version 2.9.0.final (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_21).
Type in expressions to have them evaluated.
Type :help for more information.

scala>:quit

$ md5sum /cygdrive/c/Users/jlh/AppData/Local/Temp/jansi.dll
d47102e00a05c357e91988d56ca7a635 */cygdrive/c/Users/jlh/AppData/Local/Temp/jansi.dll

$ scala32
Failed to created JLineReader: java.lang.NoClassDefFoundError: Could not initialize class org.fusesource.jansi.internal.Kernel32
Falling back to SimpleReader.
Welcome to Scala version 2.9.0.final (Java HotSpot(TM) Client VM, Java 1.6.0_18).
Type in expressions to have them evaluated.
Type :help for more information.

scala> :quit

$ md5sum /cygdrive/c/Users/jlh/AppData/Local/Temp/jansi.dll
d47102e00a05c357e91988d56ca7a635 */cygdrive/c/Users/jlh/AppData/Local/Temp/jansi.dll

$ rm /cygdrive/c/Users/jlh/AppData/Local/Temp/jansi.dll

$ scala32
Welcome to Scala version 2.9.0.final (Java HotSpot(TM) Client VM, Java 1.6.0_18).
Type in expressions to have them evaluated.
Type :help for more information.

scala> :quit

$ md5sum /cygdrive/c/Users/jlh/AppData/Local/Temp/jansi.dll
2452a4f2c62c0447948444cfb0f9f428 */cygdrive/c/Users/jlh/AppData/Local/Temp/jansi.dll

For the end user, the work around is to delete the dll del %TEMP%\jansi.dll.

@scabug
Copy link
Author

scabug commented Jun 16, 2011

Imported From: https://issues.scala-lang.org/browse/SI-4703?orig=1
Reporter: huynhjl
Affected Versions: 2.9.0

@scabug
Copy link
Author

scabug commented Jun 17, 2011

huynhjl said:
I also added an issue in the jansi github project.

@scabug
Copy link
Author

scabug commented Jun 18, 2011

@paulp said:
I can't imagine how long this might have gone undiagnosed without this ticket. Nice job.

@scabug
Copy link
Author

scabug commented Jun 19, 2011

Hiram Chirino (chirino) said:
Jansi 1.6 has just been released /w the fix.

@scabug
Copy link
Author

scabug commented Jun 19, 2011

huynhjl said:
Thank you Hiram.

@scabug
Copy link
Author

scabug commented Jun 19, 2011

@paulp said:
Can someone tell me if this is fixed since r25109?

@scabug
Copy link
Author

scabug commented Jun 20, 2011

huynhjl said:
Yes, I pulled from github, compiled and tested with build/pack/bin/scala and it's fixed (checked that the dll have the bit model in it and started a few alternate 32/64 bit sessions).

@scabug
Copy link
Author

scabug commented Jun 20, 2011

@paulp said:
Then, I declare fixed.

@scabug
Copy link
Author

scabug commented Dec 20, 2011

Henning Hoefer (hho) said:
Was r25109 before 2.9.1.final?

I'm asking, since this doesn't seem to be fixed in 2.9.1.final -- if I switch between a 32- and a 64-bit-JDK I always get the "Failed to created JLineReader"...

@scabug
Copy link
Author

scabug commented Dec 20, 2011

huynhjl said (edited on Dec 20, 2011 3:22:03 PM UTC):
The fix did not make it into 2.9.1. But I do see it in the latest nightly build. I based that on doing {{dir %TEMP%\jan*}}. With the fix it creates {{jansi-32.dll}}, without it just creates {{jansi.dll}}. As a workaround, may be you can add a {{del %TEMP%\jansi.dll}} to your {{scala.bat}}?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants