Re: [fpc-devel] sqlite support for Android
Umm, I merged the pthreads Android fixes from bug 18833 to my built, rebuilt it and added cthreads to my uses clause but I still get the exact same crash inside libsqlite.so =( Any ideas? My crash is: UNCHER] flg=0x1020 cmp=com.pascal.lcltest/.LCLActivity bnds=[120,148][180,211] } D/AK8973 ( 78): Compass Start D/Sensors ( 99): open_akm, fd=111 I/DEBUG ( 70): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** I/DEBUG ( 70): Build fingerprint: 'htc_wwe/htc_buzz/buzz/buzz:2.2.1/FRG83D/295397:user/release-keys' I/DEBUG ( 70): pid: 2459, tid: 2459 com.pascal.lcltest I/DEBUG ( 70): thread: .pascal.lcltest I/DEBUG ( 70): signal 4 (SIGILL), fault addr a8b41314 I/DEBUG ( 70): r0 42a01538 r1 42a7b460 r2 81594f78 r3 81580114 I/DEBUG ( 70): r4 42a7b300 r5 a8b41311 r6 813cc8a8 r7 0001 I/DEBUG ( 70): r8 81345928 r9 814d72f4 10 0002 fp I/DEBUG ( 70): ip bec26d60 sp bec27198 lr 813b0c54 pc a8b41314 cpsr 2010 I/DEBUG ( 70): #00 pc 00041314 /system/lib/libsqlite.so I/DEBUG ( 70): #01 pc 0001057c /system/lib/libc.so I/DEBUG ( 70): I/DEBUG ( 70): code around pc: I/DEBUG ( 70): a8b412f4 a029a697 b60e b613 9d18 I/DEBUG ( 70): a8b41304 4b771290 f7ffb510 bd10fe71 2206b510 I/DEBUG ( 70): a8b41314 f7ff2300 bd10fe6b 4c23b5f0 2300b085 I/DEBUG ( 70): a8b41324 600b9003 1c0d447c fcfef7ce d1381e06 I/DEBUG ( 70): a8b41334 f7c92000 491dfeb1 18601c07 78043064 I/DEBUG ( 70): I/DEBUG ( 70): code around lr: I/DEBUG ( 70): 813b0c34 e51b002c e350 059f2048 01a2 I/DEBUG ( 70): 813b0c44 e59f2044 e5925000 e1a0e00f e1a0f005 I/DEBUG ( 70): 813b0c54 e1a01000 e1a4 eb22 ebf54fe4 I/DEBUG ( 70): 813b0c64 e24b002c ebf528a3 e3a0 e50b002c I/DEBUG ( 70): 813b0c74 e51b0064 e350 1bf55059 e91ba830 I/DEBUG ( 70): I/DEBUG ( 70): stack: I/DEBUG ( 70): bec27158 ab2494dc /system/lib/libskia.so I/DEBUG ( 70): bec2715c bec27488 [stack] I/DEBUG ( 70): bec27160 0001 I/DEBUG ( 70): bec27164 bec27488 [stack] I/DEBUG ( 70): bec27168 0001 I/DEBUG ( 70): bec2716c 422c /system/framework/framework.odex I/DEBUG ( 70): bec27170 4218 /system/framework/framework.odex I/DEBUG ( 70): bec27174 0085 I/DEBUG ( 70): bec27178 I/DEBUG ( 70): bec2717c 4051 I/DEBUG ( 70): bec27180 002a I/DEBUG ( 70): bec27184 42a7b300 I/DEBUG ( 70): bec27188 813b0ba8 /data/data/com.pascal.lcltest/lib/liblclapp.so I/DEBUG ( 70): bec2718c 813cc8a8 /data/data/com.pascal.lcltest/lib/liblclapp.so I/DEBUG ( 70): bec27190 42a7b300 I/DEBUG ( 70): bec27194 813b0c20 /data/data/com.pascal.lcltest/lib/liblclapp.so I/DEBUG ( 70): #00 bec27198 ab249d8c /system/lib/libskia.so I/DEBUG ( 70): bec2719c afd10580 /system/lib/libc.so I/DEBUG ( 70): #01 bec271a0 00146b00 [heap] I/DEBUG ( 70): bec271a4 ab249d8c /system/lib/libskia.so I/DEBUG ( 70): bec271a8 I/DEBUG ( 70): bec271ac afd10460 /system/lib/libc.so I/DEBUG ( 70): bec271b0 I/DEBUG ( 70): bec271b4 42a7b300 I/DEBUG ( 70): bec271b8 813b0ba8 /data/data/com.pascal.lcltest/lib/liblclapp.so I/DEBUG ( 70): bec271bc 813cc8a8 /data/data/com.pascal.lcltest/lib/liblclapp.so I/DEBUG ( 70): bec271c0 0001 I/DEBUG ( 70): bec271c4 81345928 /data/data/com.pascal.lcltest/lib/liblclapp.so I/DEBUG ( 70): bec271c8 814d72f4 /data/data/com.pascal.lcltest/lib/liblclapp.so I/DEBUG ( 70): bec271cc 0002 I/DEBUG ( 70): bec271d0 bec27214 [stack] I/DEBUG ( 70): bec271d4 bec27198 [stack] I/DEBUG ( 70): bec271d8 813b0bd8 /data/data/com.pascal.lcltest/lib/liblclapp.so I/DEBUG ( 70): bec271dc bec271b4 [stack] I/DEBUG ( 70): bec271e0 bec272c0 [stack] I/DEBUG ( 70): bec271e4 0001 So analyzing this I see: A I/DEBUG ( 70): bec27188 813b0ba8 /data/data/com.pascal.lcltest/lib/liblclapp.so B I/DEBUG ( 70): bec2718c 813cc8a8 /data/data/com.pascal.lcltest/lib/liblclapp.so C I/DEBUG ( 70): bec27194 813b0c20 /data/data/com.pascal.lcltest/lib/liblclapp.so A I/DEBUG ( 70): bec271b8 813b0ba8 /data/data/com.pascal.lcltest/lib/liblclapp.so B I/DEBUG ( 70): bec271bc 813cc8a8 /data/data/com.pascal.lcltest/lib/liblclapp.so D I/DEBUG ( 70): bec271c4 81345928 /data/data/com.pascal.lcltest/lib/liblclapp.so E I/DEBUG ( 70): bec271c8 814d72f4 /data/data/com.pascal.lcltest/lib/liblclapp.so F I/DEBUG ( 70): bec271d8 813b0bd8 /data/data/com.pascal.lcltest/lib/liblclapp.so Here the 2 top numbers of the address 81xx are irrelevant Element A: 003b0b6c SQLITE3CONN_TSQLITE3CONNECTION_$__ROLLBACKRETAINING$TSQLHANDLE: ... 3b0b94:
[fpc-devel] sqlite support for Android
Hello,
In Android a dlopen operation without a full path will fail:
sqliteDLL:=DlOpen('libsqlite.so',RTLD_LAZY); == fails
sqliteDLL:=DlOpen('libsqlite3.so',RTLD_LAZY); == fails
sqliteDLL:=DlOpen('/data/data/com.pascal.lcltest/lib/libsqlite3.so',RTLD_LAZY);
== fails
sqliteDLL:=DlOpen('/data/data/com.pascal.lcltest/lib/libsqlite.so',RTLD_LAZY);
== works
sqliteDLL:=DlOpen('/system/lib/libsqlite.so',RTLD_LAZY); == works
So the existing sqlite bindings fail. The simples solution would be
hardcode for Android /system/lib/libsqlite.so but this is somewhat of
a grey area since this library is not guaranteed to exist. The other
option is placing it in our lib folder, but then you need to pass the
entire path for dlopen and this path will necessarely change with each
project, for example: '/data/data/com.pascal.lcltest/lib/libsqlite.so'
constains the name of the project com.pascal.lcltest
The solution would be to make this library name a variable then, but
this won't work because the sqlite bindings need to support static
linking too =O So maybe a variable only in the case of dynamic
binding.
Well, so basically I am just sending this e-mail to start talks about
what kind of solution would be accepted, maybe someone has better
ideas then I had. I am tempted towards:
{$ifdef Android}
libsqlite3 = '/system/lib/libsqlite.so';
{$else}
...
Which is what I already commited to fpc4android
--
Felipe Monteiro de Carvalho
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] sqlite support for Android
On Mon, 2 Apr 2012, Felipe Monteiro de Carvalho wrote:
Hello,
In Android a dlopen operation without a full path will fail:
sqliteDLL:=DlOpen('libsqlite.so',RTLD_LAZY); == fails
sqliteDLL:=DlOpen('libsqlite3.so',RTLD_LAZY); == fails
sqliteDLL:=DlOpen('/data/data/com.pascal.lcltest/lib/libsqlite3.so',RTLD_LAZY);
== fails
sqliteDLL:=DlOpen('/data/data/com.pascal.lcltest/lib/libsqlite.so',RTLD_LAZY);
== works
sqliteDLL:=DlOpen('/system/lib/libsqlite.so',RTLD_LAZY); == works
So the existing sqlite bindings fail. The simples solution would be
hardcode for Android /system/lib/libsqlite.so but this is somewhat of
a grey area since this library is not guaranteed to exist. The other
option is placing it in our lib folder, but then you need to pass the
entire path for dlopen and this path will necessarely change with each
project, for example: '/data/data/com.pascal.lcltest/lib/libsqlite.so'
constains the name of the project com.pascal.lcltest
The solution would be to make this library name a variable then, but
this won't work because the sqlite bindings need to support static
linking too =O So maybe a variable only in the case of dynamic
binding.
This variable already exists: SQLiteDefaultLibrary.
Well, so basically I am just sending this e-mail to start talks about
what kind of solution would be accepted, maybe someone has better
ideas then I had. I am tempted towards:
{$ifdef Android}
libsqlite3 = '/system/lib/libsqlite.so';
{$else}
This is the most practical solution, just redefine the constant.
The SQLiteDefaultLibrary variable is initialized from this constant.
In case a private library is used, users can always explicitly do a
InitialiseSQLite('/path/to/private/sqlite.so');
to override the default behaviour.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] sqlite support for Android
Felipe Monteiro de Carvalho wrote on Mon, 02 Apr 2012: In Android a dlopen operation without a full path will fail: A bit of googling suggests that the above statement is wrong: http://groups.google.com/group/android-ndk/browse_thread/thread/2779732b85fef9b3#f0cb99298fa286e1 Some help on debugging Android shared library loading problems: http://mpigulski.blogspot.com/2010/09/debugging-dlopen-unsatisfiedlinkerror.html And keep in mind this problem when testing: http://code.google.com/p/android/issues/detail?id=22143 Jonas This message was sent using IMP, the Internet Messaging Program. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] sqlite support for Android
On Tue, Apr 3, 2012 at 11:47 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
In Android a dlopen operation without a full path will fail:
A bit of googling suggests that the above statement is wrong:
http://groups.google.com/group/android-ndk/browse_thread/thread/2779732b85fef9b3#f0cb99298fa286e1
ops, it seams you are correct. In a new test sending only sqlite.so
worked properly ... no idea why the first test failed. Probably I was
using an old APK or library which tested against libsqlite3.so which
fails.
Continuing I have an even much wierder issue. The following code:
procedure TForm3.Button2Click(Sender : TObject) ;
begin
SQLite3Connection1.ExecuteDirect('CREATE TABLE IF NOT EXISTS PRODUTOS ( '+
'CODPRODUTO INTEGER NOT NULL, '+
'DESCRICAO VARCHAR(50), '+
'PRECO NUMERIC(12,3), '+
'ALTERADO TIMESTAMP, '+
' CONSTRAINT PK_PRODUTOS PRIMARY KEY (CODPRODUTO)); ');
end;
Causes a very wierd crash without stacktrace and no way to work
around, but only in LCL-CustomDrawn it works fine in LCL-Gtk2:
(gdb) break fpc_raiseexception
Breakpoint 1 at 0x8058d46
(gdb) cont
Continuing.
MouseMove x=47 y=93
MouseMove x=-9 y=63
MouseMove x=-79 y=47
MouseMove x=-57 y=58
MouseMove x=-26 y=63
[Thread debugging using libthread_db enabled]
Cannot find new threads: generic error
Missing debug package(s), you should install: sqlite3-debug-3.7.9-1.1.mga1.i586
(gdb) bt
Target is executing.
This package does not exist. And if I add cthreads as the first unit
in the project automagically it starts working o.O It looks really
wierd that sqlite is using threading behind my back, or is it sqldb?
Very wierd ... the nasty thing here is that cthreads does not work in
Android so I will have to first get it into working to have sqlite
support. Really unexpected to need threading for sqlite...
--
Felipe Monteiro de Carvalho
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] sqlite support for Android
On Tue, 3 Apr 2012, Felipe Monteiro de Carvalho wrote:
On Tue, Apr 3, 2012 at 11:47 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
In Android a dlopen operation without a full path will fail:
A bit of googling suggests that the above statement is wrong:
http://groups.google.com/group/android-ndk/browse_thread/thread/2779732b85fef9b3#f0cb99298fa286e1
ops, it seams you are correct. In a new test sending only sqlite.so
worked properly ... no idea why the first test failed. Probably I was
using an old APK or library which tested against libsqlite3.so which
fails.
Continuing I have an even much wierder issue. The following code:
procedure TForm3.Button2Click(Sender : TObject) ;
begin
SQLite3Connection1.ExecuteDirect('CREATE TABLE IF NOT EXISTS PRODUTOS ( '+
'CODPRODUTO INTEGER NOT NULL, '+
'DESCRICAO VARCHAR(50), '+
'PRECO NUMERIC(12,3), '+
'ALTERADO TIMESTAMP, '+
' CONSTRAINT PK_PRODUTOS PRIMARY KEY (CODPRODUTO)); ');
end;
Causes a very wierd crash without stacktrace and no way to work
around, but only in LCL-CustomDrawn it works fine in LCL-Gtk2:
(gdb) break fpc_raiseexception
Breakpoint 1 at 0x8058d46
(gdb) cont
Continuing.
MouseMove x=47 y=93
MouseMove x=-9 y=63
MouseMove x=-79 y=47
MouseMove x=-57 y=58
MouseMove x=-26 y=63
[Thread debugging using libthread_db enabled]
Cannot find new threads: generic error
Missing debug package(s), you should install: sqlite3-debug-3.7.9-1.1.mga1.i586
(gdb) bt
Target is executing.
This package does not exist. And if I add cthreads as the first unit
in the project automagically it starts working o.O It looks really
wierd that sqlite is using threading behind my back, or is it sqldb?
SQLDb does not use threads by itself.
It can be that the sqlite library uses threads, and if a SQLite callback
is done from a different thread, then the RTL may present you with a nice error.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
