sqlite-jdbc icon indicating copy to clipboard operation
sqlite-jdbc copied to clipboard
verified publisher icon xerial

Armv5 support

Open wassinki opened this issue 6 years ago • 11 comments

We are using the xerial driver for the armv5 and armv7. The armv7 is working correctly with the native binaries. The armv5 however results into crashes:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGILL (0x4) at pc=0x4c316de4, pid=999, tid=0x408c3490
#
# JRE version: OpenJDK Runtime Environment (8.0_33-b144) (build 1.8.0_33-b144)
# Java VM: OpenJDK Embedded Client VM (25.33-b144 mixed mode linux-aarch32 )
# Problematic frame:
# C  [sqlite-3.23.1-52564231-cd6a-4f50-a973-c8c078bc77d2-libsqlitejdbc.so+0x3fde4]
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again

It seems to be related with an unsupported vpush instruction after decompile to assembly. Is it possible to update the build chain to support Armv5. If not, can you explain which architecture is meant by 'Linux/arm'? Since all other architectures directories names are related to the architecture (Armv6, Armv7) .

wassinki avatar Jan 24 '19 16:01 wassinki

I am experiencing a similar issue with armv5tel and sqlite-jdbc-3.27.2 I get a 1298 Segmentation fault Here is the complete dump file

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGILL (0x4) at pc=0x4813f11c, pid=1298, tid=1082352752
#
# JRE version: Java(TM) SE Embedded Runtime Environment (7.0_71-b14) (build 1.7.0_71-b14)
# Java VM: Java HotSpot(TM) Embedded Client VM (24.71-b01 mixed mode linux-arm )
# Problematic frame:
# C  [sqlite-3.27.2-007dba3f-93e7-44d0-a335-01c62f806a89-libsqlitejdbc.so+0x3f11c]  Java_org_sqlite_core_NativeDB_clear_1progress_1handler+0x2fef8
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---------------  T H R E A D  ---------------

Current thread (0x00019400):  JavaThread "main" [_thread_in_native, id=1310, stack(0x407e7000,0x40837000)]

siginfo:si_signo=SIGILL: si_errno=0, si_code=1 (ILL_ILLOPC), si_addr=0x4813f11c

Registers:
  r0  = 0x40835338
  r1  = 0x481e0d10
  r2  = 0x40835374
  r3  = 0x40835374
  r4  = 0x00000000
  r5  = 0x4806c4c0
  r6  = 0x00000000
  r7  = 0x00000001
  r8  = 0x00000201
  r9  = 0x0000001e
  r10 = 0x40835390
  fp  = 0x00000000
  r12 = 0x00000201
  sp  = 0x40835314
  lr  = 0x48140a78
  pc  = 0x4813f11c
  cpsr = 0x20000010

Top of Stack: (sp=0x40835314)
0x40835314:   00000000 4806c4c0 00000000 00000001
0x40835324:   00000201 0000001e 40835390 00000000
0x40835334:   48140a78 00000000 4806c4c0 00000201
0x40835344:   00000000 00000000 00000000 481fc1e4
0x40835354:   48069420 4806c4c0 48140aac ffffffff
0x40835364:   40835374 00000010 48148f7c 481e0d10
0x40835374:   48069420 00000410 400da5c0 481e0568
0x40835384:   481e0568 481e0568 401868c0 00000410

Instructions: (pc=0x4813f11c)
0x4813f0fc:   000a1ab8 000a5424 000a35b4 000a584c
0x4813f10c:   000a1a08 000a539c 000a1968 e92d4ff0
0x4813f11c:   ed2d8b02 e1a07001 e5d03015 e24dd094
0x4813f12c:   e2133002 11a03002 e58d200c 15932000

Register to memory mapping:

  r0  = 0x40835338
0x40835338 is pointing into the stack for thread: 0x00019400

  r1  = 0x481e0d10
0x481e0d10: <offset 0xe0d10> in /tmp/sqlite-3.27.2-007dba3f-93e7-44d0-a335-01c62f806a89-libsqlitejdbc.so at 0x48100000

  r2  = 0x40835374
0x40835374 is pointing into the stack for thread: 0x00019400

  r3  = 0x40835374
0x40835374 is pointing into the stack for thread: 0x00019400

  r4  = 0x00000000
0x00000000 is an unknown value

  r5  = 0x4806c4c0
0x4806c4c0 is an unknown value

  r6  = 0x00000000
0x00000000 is an unknown value

  r7  = 0x00000001
0x00000001 is an unknown value

  r8  = 0x00000201
0x00000201 is an unknown value

  r9  = 0x0000001e
0x0000001e is an unknown value

  r10 = 0x40835390
0x40835390 is pointing into the stack for thread: 0x00019400

  fp  = 0x00000000
0x00000000 is an unknown value

  r12 = 0x00000201
0x00000201 is an unknown value

  sp  = 0x40835314
0x40835314 is pointing into the stack for thread: 0x00019400

  lr  = 0x48140a78
0x48140a78: <offset 0x40a78> in /tmp/sqlite-3.27.2-007dba3f-93e7-44d0-a335-01c62f806a89-libsqlitejdbc.so at 0x48100000

  pc  = 0x4813f11c
0x4813f11c: <offset 0x3f11c> in /tmp/sqlite-3.27.2-007dba3f-93e7-44d0-a335-01c62f806a89-libsqlitejdbc.so at 0x48100000



Stack: [0x407e7000,0x40837000],  sp=0x40835314,  free space=312k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [sqlite-3.27.2-007dba3f-93e7-44d0-a335-01c62f806a89-libsqlitejdbc.so+0x3f11c]  Java_org_sqlite_core_NativeDB_clear_1progress_1handler+0x2fef8

jadbaz avatar Jun 12 '19 16:06 jadbaz

@wassinki did you manage to resolve this somehow?

I tried so many things including compiling on armv5 and it didn't work

I also tried using 3.7.2 (the latest version that includes pure-java support) (along with even older releases) and that didn't work either. It basically used up all the RAM (128MB) and hung there. I'm also wondering if it would have worked with more RAM but I don't know where I can get my hands on an armv5 device with a lot of RAM.

jadbaz avatar Jun 19 '19 15:06 jadbaz

At the moment, we use a custom build so version. You can tell the driver using this one by adding the environment variables:

org.sqlite.lib.path=<> org.sqlite.lib.name=libsqlitejdbc.so

This version of the so however doesn't belong to the current version of the jar, although it still seems to work anyway. I think we should recompile it for the current version. Feel free to use/try this so file as long as needed :).

libsqlitejdbc.so.zip

wassinki avatar Jun 20 '19 06:06 wassinki

IT WORKED!!! You just saved me so many days (or weeks) of banging my head against a brick wall

For some reason I couldn't get it to work when I compiled it

I compiled it with version 3.27.2.1 by running make jni-header native in the following environment:

  • arch: armv5tel
  • os: debian 6.0.10
  • java: openjdk 1.6.0_18
  • cc: gcc (Debian 4.4.5-8) 4.4.5 by running .

I got the following when trying to run it with my compiled libjdbcsqlite.so:

Exception in thread "main" java.lang.UnsatisfiedLinkError: org.sqlite.core.NativeDB._open_utf8([BI)V
        at org.sqlite.core.NativeDB._open_utf8(Native Method)
        at org.sqlite.core.NativeDB._open(NativeDB.java:78)
        at org.sqlite.core.DB.open(DB.java:195)
        at org.sqlite.SQLiteConnection.open(SQLiteConnection.java:243)
        at org.sqlite.SQLiteConnection.<init>(SQLiteConnection.java:61)
        at org.sqlite.jdbc3.JDBC3Connection.<init>(JDBC3Connection.java:28)
        at org.sqlite.jdbc4.JDBC4Connection.<init>(JDBC4Connection.java:21)
        at org.sqlite.JDBC.createConnection(JDBC.java:115)
        at org.sqlite.JDBC.connect(JDBC.java:90)
        at java.sql.DriverManager.getConnection(DriverManager.java:620)
        at java.sql.DriverManager.getConnection(DriverManager.java:169)
        at Main.main(Main.java:29)

jadbaz avatar Jun 20 '19 06:06 jadbaz

@wassinki so I have 2 questions:

  • What version of the sqlite-jdbc did you compile this with?
  • Did you compile it the same way I did or some other way?

jadbaz avatar Jun 20 '19 07:06 jadbaz

I pushed this to my fork jadbaz/sqlite-jdbc and released a jar at jadbaz/sqlite-jdbc/releases/tag/3.27.2.1-armv5-patch that includes this fix.

Unfortunately I can't PR this as it is a patch and doesn't actually fix the root cause.

jadbaz avatar Jun 20 '19 10:06 jadbaz

I found the problem with the armv5. It is indeed using floating point instructions. The line in Makefile.common: Linux-arm_CCFLAGS := -I$(JAVA_HOME)/include -Ilib/inc_linux -Os -fPIC -mfloat-abi=softfp -mfpu=vfp -fvisibility=hidden

If we update this one to Linux-arm_CCFLAGS := -I$(JAVA_HOME)/include -Ilib/inc_linux -Os -fPIC -mfloat-abi=soft -fvisibility=hidden

Then it is working on a sheeva vpu.

Is it possbile to use this code in the real library? Or maybe to add an additional machine configuration arm5v_soft, that can be enabled using system property?

wassinki avatar May 31 '21 14:05 wassinki

Is this still happening on the latest version?

gotson avatar Jul 28 '22 09:07 gotson

Yes, it is still not working, because the current config enables amongst others the vfp extension which is not supported. If we disable this option and only use soft floating point (as explained above), it is working fine.

wassinki avatar Aug 17 '22 09:08 wassinki

Thanks for the feedback, now i get a better grasp of what the issue is.

I think we have 3 choices really:

  1. enhance OSInfo to be able to detect cpu features (like vfp extension or hard float), and have different flavors of the binary that can then be loaded accordingly
  2. use a system property, as you mentioned. Since we already have a way to override the native lib with one provided, i don't think that would really bring value.
  3. change the armv5 build as you proposed, removing vfp and using soft float instead.

I think 3 is the simplest. I don't know how many armv5 cpu have vfp or not, and even though it probably means some kind of performance downgrade, it is probably for the better, as it would improve compatibility.

WDYT @wassinki ?

gotson avatar Aug 17 '22 09:08 gotson

Thanks for the quick reply. As long as there are not to many objections to remove hte usage of hard float instruction, I would go for option 3, because that is the easiest solution. The others will result in more maintenance.

Kind regards,

Ingo

wassinki avatar Aug 17 '22 15:08 wassinki