search

pschichtel / JavaCAN

A simple JNI wrapper for the socketcan API provided by the Linux kernel. As it is wrapping a Linux Kernel API, it is intended for use on Linux only.
https://schich.tel
MIT License
49 stars 21 forks source link

MavenCentral download problem and JVM crashing #37

Closed Boronyak closed 2 years ago

Boronyak commented 2 years ago

Hi!

I am currently using your library in my CAN parser project. I am working on Eclipse and using Gradle to build. I added the correct dependency to the build.gradle file, but can not download the 3.x versions for some reason. There is not any problem during building, but after that the library does not appear in the "project and external dependencies" folder and I can not use it. Only 2.x working, so I use 2.3.0 now. Can you tell me what can cause this? Did you face it anytime in the past?

I would like to run my application on a Cohda MK5 device. Its architecture is armv7l, so the app try to load the armv7 shared object file, but JVM crashes with a fatal error similarly in the issue #24 . I have attached the log file and add some more details about my system:

root@MK5:~# cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 10 (v7l) BogoMIPS : 3.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x2 CPU part : 0xc09 CPU revision : 10

processor : 1 model name : ARMv7 Processor rev 10 (v7l) BogoMIPS : 3.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x2 CPU part : 0xc09 CPU revision : 10

Hardware : Freescale i.MX6 Quad/DualLite (Device Tree) Revision : 0000 Serial : 0000000000000000

root@MK5:~# uname -p armv7l

root@MK5:~# lscpu Architecture: armv7l Byte Order: Little Endian CPU(s): 2 On-line CPU(s) list: 0,1 Thread(s) per core: 1 Core(s) per socket: 2 Socket(s): 1 Model name: ARMv7 Processor rev 10 (v7l) CPU max MHz: 792.0000 CPU min MHz: 396.0000 Hypervisor vendor: (null) Virtualization type: full

Java method System.getProperty("os.arch") returns arm only. Can you add compatibility for armv7l or I should try to build the shared object file?

Regards,

Adam

hs_err_pid1595.log

pschichtel commented 2 years ago

@Boronyak sorry for the late response, github notifications and I are not friends. SIGILL definitely indicates an incompatible architecture.

I'd prefer if we can get version 3 going for you. Can you elaborate on that issue?

pschichtel commented 2 years ago

these are the artifacts that should work:

Can you confirm that these are the ones you used?

I'm not currently building armv7l, but as far as I understand the armv7 binary should work too. I could add explicit armv7l support later today.

Boronyak commented 2 years ago

@pschichtel I have successfully added these jar files to my project, but I had to add also slf4j and duplicate strategy property to built the jar file. I try to run it on Cohda but now I get the following error:

java.lang.UnsatisfiedLinkError: /tmp/javacan-core-11461710119285914790/libjavacan-core.so: /lib/arm-linux-gnueabihf/libc.so.6: version 'GLIBC_2.28' not found (required by /tmp/javacan-core-11461710119285914790/libjavacan-core.so) at java.base/jdk.internal.loader.NativeLibraries.load(Native Method) at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(Unknown Source) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown Source) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown Source) at java.base/java.lang.ClassLoader.loadLibrary(Unknown Source) at java.base/java.lang.Runtime.load0(Unknown Source) at java.base/java.lang.System.load(Unknown Source) at tel.schich.javacan.platform.Platform.loadFromClassPath(Platform.java:113) at tel.schich.javacan.platform.Platform.loadExplicitLibrary(Platform.java:99) at tel.schich.javacan.platform.Platform.loadNativeLibrary(Platform.java:68) at tel.schich.javacan.JavaCAN.initialize(JavaCAN.java:44) at tel.schich.javacan.SocketCAN.<clinit>(SocketCAN.java:32) at tel.schich.javacan.CanChannels.newRawChannel(CanChannels.java:45) at can.CanInterface.<init>(CanInterface.java:21) at api.Main.main(Main.java:57)

On Cohda, Ubuntu 16.04 is running and only glibc 2.23 is available. It is not possible to upgrade to 18.04 and as I have read, install glibc 2.28 manually is risky. Do you have a version which uses 2.23 or older?

pschichtel commented 2 years ago

hmm I'm building using dockcross, not sure how much I can do about the glibc version except maybe using older images. I've seen the dockcross' armv7l image uses musl libc, would that be an option?

Boronyak commented 2 years ago

Yes, but only 1.1.9 is available. I do not know what is the required version.

pschichtel commented 2 years ago

I've build an armv7l version with musl libc:

https://oss.sonatype.org/service/local/repositories/snapshots/content/tel/schich/javacan-core/3.1.1-SNAPSHOT/javacan-core-3.1.1-20220301.202605-2-armv7l.jar

pschichtel commented 2 years ago

you can also now override the docker image being used to cross-compile, but the interface must be compatible with dockcross.

Boronyak commented 2 years ago

I have added the armv7l jar file and installed musl, but now the following error is coming:

java.lang.UnsatisfiedLinkError: /tmp/javacan-core-5290316483724111401/libjavacan-core.so: /usr/lib/arm-linux-gnueabihf/libc.so: invalid ELF header at java.base/jdk.internal.loader.NativeLibraries.load(Native Method) at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(Unknown Source) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown Source) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(Unknown Source) at java.base/java.lang.ClassLoader.loadLibrary(Unknown Source) at java.base/java.lang.Runtime.load0(Unknown Source) at java.base/java.lang.System.load(Unknown Source) at tel.schich.javacan.platform.Platform.loadFromClassPath(Platform.java:113) at tel.schich.javacan.platform.Platform.loadExplicitLibrary(Platform.java:99) at tel.schich.javacan.platform.Platform.loadNativeLibrary(Platform.java:68) at tel.schich.javacan.JavaCAN.initialize(JavaCAN.java:44) at tel.schich.javacan.SocketCAN.<clinit>(SocketCAN.java:32) at tel.schich.javacan.CanChannels.newRawChannel(CanChannels.java:45) at can.CanInterface.<init>(CanInterface.java:21) at api.Main.main(Main.java:57)

I did not find any useful information on the internet to solve this problem. Am I missing some package or configuration?

pschichtel commented 2 years ago

apparently your libc.so is not an actual library. not sure how that happens and how to solve it.

pschichtel commented 2 years ago

I could try statically linking musl

pschichtel commented 2 years ago

@Boronyak Can you give this one a try: https://oss.sonatype.org/content/repositories/snapshots/tel/schich/javacan-core/3.1.1-SNAPSHOT/javacan-core-3.1.1-20220306.150726-3-armv7l.jar

I should be linked statically with musl libc (so you don't even need it installed).

Boronyak commented 2 years ago

Unfortunately I am getting the same error.

Boronyak commented 2 years ago

@Boronyak Can you give this one a try: https://oss.sonatype.org/content/repositories/snapshots/tel/schich/javacan-core/3.1.1-SNAPSHOT/javacan-core-3.1.1-20220306.150726-3-armv7l.jar

I should be linked statically with musl libc (so you don't even need it installed).

@pschichtel I aggree that this static linking would be an option too. I have found this article on github. The problem is similar as mine and they suggest to build on a machine which has lower glibc version. Is is possible to do that or it only depends on which docker image you use?

pschichtel commented 2 years ago

You can override the build container on lastest master (it's documented in the readme in the building section). I haven't immediately found an appropriate version of dockcross that has glibc 2.23, but if you find one you can just use that version of the container.

pschichtel commented 2 years ago

I think there is also some documentation on dockcross' side on how to build custom dockcross containers.

Boronyak commented 2 years ago

@Boronyak Can you give this one a try: https://oss.sonatype.org/content/repositories/snapshots/tel/schich/javacan-core/3.1.1-SNAPSHOT/javacan-core-3.1.1-20220306.150726-3-armv7l.jar

I should be linked statically with musl libc (so you don't even need it installed).

@pschichtel It is possible that I misunderstood something. This jar contains the native component with statically linked musl libc? If yes, then why is it try to use glibc?

pschichtel commented 2 years ago

file also identifies it as dynamically linked... I'll have a look...

pschichtel commented 2 years ago

Just checked the binaries and it doesn't look like it depends on any libc:

$ readelf -d armv7l/libjavacan-core.so

Dynamic section at offset 0x8f38 contains 21 entries:
  Tag        Type                         Name/Value
 0x0000000c (INIT)                       0x1f14
 0x0000000d (FINI)                       0x72c4
 0x00000019 (INIT_ARRAY)                 0x18f2c
 0x0000001b (INIT_ARRAYSZ)               4 (bytes)
 0x0000001a (FINI_ARRAY)                 0x18f30
 0x0000001c (FINI_ARRAYSZ)               4 (bytes)
 0x00000004 (HASH)                       0xf4
 0x6ffffef5 (GNU_HASH)                   0x458
 0x00000005 (STRTAB)                     0xf84
 0x00000006 (SYMTAB)                     0x824
 0x0000000a (STRSZ)                      3501 (bytes)
 0x0000000b (SYMENT)                     16 (bytes)
 0x00000003 (PLTGOT)                     0x19000
 0x00000002 (PLTRELSZ)                   384 (bytes)
 0x00000014 (PLTREL)                     REL
 0x00000017 (JMPREL)                     0x1d94
 0x00000011 (REL)                        0x1d34
 0x00000012 (RELSZ)                      96 (bytes)
 0x00000013 (RELENT)                     8 (bytes)
 0x6ffffffa (RELCOUNT)                   7
 0x00000000 (NULL)                       0x0

For reference here is the output for the x86_64 binary, notice the first entry:

$ readelf -d x86_64/libjavacan-core.so

Dynamic section at offset 0x5e20 contains 24 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000c (INIT)               0x2000
 0x000000000000000d (FINI)               0x34ac
 0x0000000000000019 (INIT_ARRAY)         0x6e10
 0x000000000000001b (INIT_ARRAYSZ)       8 (bytes)
 0x000000000000001a (FINI_ARRAY)         0x6e18
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x000000006ffffef5 (GNU_HASH)           0x260
 0x0000000000000005 (STRTAB)             0xd70
 0x0000000000000006 (SYMTAB)             0x4d0
 0x000000000000000a (STRSZ)              3271 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000003 (PLTGOT)             0x7000
 0x0000000000000002 (PLTRELSZ)           864 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x1bb8
 0x0000000000000007 (RELA)               0x1b10
 0x0000000000000008 (RELASZ)             168 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffe (VERNEED)            0x1af0
 0x000000006fffffff (VERNEEDNUM)         1
 0x000000006ffffff0 (VERSYM)             0x1a38
 0x000000006ffffff9 (RELACOUNT)          3
 0x0000000000000000 (NULL)               0x0
pschichtel commented 2 years ago

Can you make sure that you are really using the right library?

Boronyak commented 2 years ago

@Boronyak Can you give this one a try: https://oss.sonatype.org/content/repositories/snapshots/tel/schich/javacan-core/3.1.1-SNAPSHOT/javacan-core-3.1.1-20220306.150726-3-armv7l.jar

I should be linked statically with musl libc (so you don't even need it installed).

I have downloaded this jar file and replaced the old one in my project and built again the executable jar. I got the same elf header error. I have just checked the native library with the same command as you and I see libc.so as a needed library. Maybe did you upload a wrong jar file?

pschichtel commented 2 years ago

I just downloaded this:
https://oss.sonatype.org/content/repositories/snapshots/tel/schich/javacan-core/3.1.1-SNAPSHOT/javacan-core-3.1.1-20220310.224643-5-armv7l.jar

That has been build via GitHub Action:
https://github.com/pschichtel/JavaCAN/runs/5503667342

The SHA256 of the javacan-core-3.1.1-20220310.224643-5-armv7l.jar file:
6715eb028b916a9b5644971b6cc3cd9e01a43b73d26a408fbaab99ad3b6b0a00

The SHA256 of the libjavacan-core.so file:
21ffc52a6b7767826d8ca45c33da772f47f6697bb3b2173676f50d39e1516d91

$ readelf -d libjavacan-core.so

Dynamic section at offset 0x8f38 contains 21 entries:
  Tag        Type                         Name/Value
 0x0000000c (INIT)                       0x1f14
 0x0000000d (FINI)                       0x72c4
 0x00000019 (INIT_ARRAY)                 0x18f2c
 0x0000001b (INIT_ARRAYSZ)               4 (bytes)
 0x0000001a (FINI_ARRAY)                 0x18f30
 0x0000001c (FINI_ARRAYSZ)               4 (bytes)
 0x00000004 (HASH)                       0xf4
 0x6ffffef5 (GNU_HASH)                   0x458
 0x00000005 (STRTAB)                     0xf84
 0x00000006 (SYMTAB)                     0x824
 0x0000000a (STRSZ)                      3501 (bytes)
 0x0000000b (SYMENT)                     16 (bytes)
 0x00000003 (PLTGOT)                     0x19000
 0x00000002 (PLTRELSZ)                   384 (bytes)
 0x00000014 (PLTREL)                     REL
 0x00000017 (JMPREL)                     0x1d94
 0x00000011 (REL)                        0x1d34
 0x00000012 (RELSZ)                      96 (bytes)
 0x00000013 (RELENT)                     8 (bytes)
 0x6ffffffa (RELCOUNT)                   7
 0x00000000 (NULL)                       0x0
pschichtel commented 2 years ago

In recent commits I've made the maven build reproducible, so you should be able to produce the exact same hashes by building locally.

pschichtel commented 2 years ago

I just downloaded this: https://oss.sonatype.org/content/repositories/snapshots/tel/schich/javacan-core/3.1.1-SNAPSHOT/javacan-core-3.1.1-20220310.224643-5-armv7l.jar

You could manually download this jar, extract the libjavacan-core.so and put into your LD_LIBRARY_PATH. Alternatively you can set javacan.native.javacan-core.path to the absolute filesystem path to the libjavacan-core.so. The loader should prioritize this. If you enable trace logging for the tel.schich.javacan.platform.Platform logger it will tell you where it loaded the library from (I even improved the logging a bit on master just now).

Boronyak commented 2 years ago

I just downloaded this: https://oss.sonatype.org/content/repositories/snapshots/tel/schich/javacan-core/3.1.1-SNAPSHOT/javacan-core-3.1.1-20220310.224643-5-armv7l.jar

Now that works! :) Thank you very much for your help!

pschichtel commented 2 years ago

Cool, so I'll release what I have on master in the next few days as 3.2