[fpc-pascal] access violation somehow related to dlopen'ing libssl
Greetings once again! I've run into a little bit of a strange problem
that I'm hoping someone here will be able to help me figure out.
I'm using, as I suspect some of you may be, the excellent synapse
project (http://ararat.cz/synapse). I have a simple 64-bit project
which consists only of:
program syna64test;
{$mode objfpc}{$H+}
uses
ssl_openssl;
begin
end.
Admittedly, to get this to compile I had to remove the "libc"
dependency from synapse's ssl_openssl_lib.pas, but I can't see how
that would be a problem since it's not used by anything in that unit
and compiles fine without it.
So, as you can see, this program doesn't do anything except call
ssl_openssl's initialization code, which ends up in a function called
InitSSLInterface in ssl_openssl_lib.pas, which attempts to dlopen
libssl and libcrypt and then call GetProcedureAddress for various
openssl functions. Pretty standard stuff. And, of course, since libssl
isn't linked directly, ldd displays something like this:
$ ldd syna64test
linux-vdso.so.1 => (0x7fff56bff000)
libdl.so.2 => /lib/libdl.so.2 (0x7fc599613000)
libc.so.6 => /lib/libc.so.6 (0x7fc599291000)
/lib64/ld-linux-x86-64.so.2 (0x7fc59983c000)
However, the problem I run into is if my program is linked against
something else that also depends on libssl. For a simple example, if I
attempt to also link against libssh2.so like this (I actually do have
a .pas header file for libssh2, but for the sake of simplicity in this
example I'll simply use LINKLIB):
program syna64test;
{$mode objfpc}{$H+}
{$LINKLIB ssh2}
uses
ssl_openssl;
begin
end.
Now ldd shows:
$ ldd syna64test
linux-vdso.so.1 => (0x7fffe2bd)
libssh2.so.1 => /usr/lib/libssh2.so.1 (0x7fdb393f)
libdl.so.2 => /lib/libdl.so.2 (0x7fdb391ec000)
libssl.so.0.9.8 => /lib/libssl.so.0.9.8 (0x7fdb38f9b000)
libcrypto.so.0.9.8 => /lib/libcrypto.so.0.9.8 (0x7fdb38c0b000)
libz.so.1 => /lib/libz.so.1 (0x7fdb389f4000)
libc.so.6 => /lib/libc.so.6 (0x7fdb38671000)
/lib64/ld-linux-x86-64.so.2 (0x7fdb3963a000)
When I run the program, I get:
$ ./syna64test
An unhandled exception occurred at $7F5DBE8026D5 :
EAccessViolation : Access violation
$7F5DBE8026D5
$7F5DBD97AF66
$7F5DBE3D00C4
An unhandled exception occurred at $7F5DBE80D3C1 :
EAccessViolation : Access violation
$7F5DBE80D3C1
When I run it in gdb, it crashes calling GetProcedureAddress with the
dlopen'ed handle:
$ gdb ./syna64test
...
Reading symbols from
/media/truecrypt1/tlacuache/devel/seth/trunk/syna64test/bin/syna64test...done.
(gdb) r
Starting program:
/media/truecrypt1/tlacuache/devel/seth/trunk/syna64test/bin/syna64test
Program received signal SIGSEGV, Segmentation fault.
0x77de66d5 in ?? () from /lib64/ld-linux-x86-64.so.2
(gdb) bt
#0 0x77de66d5 in ?? () from /lib64/ld-linux-x86-64.so.2
#1 0x76f5ef66 in ?? () from /lib/libc.so.6
#2 0x779b40c4 in ?? () from /lib/libdl.so.2
#3 0x77dea9c6 in ?? () from /lib64/ld-linux-x86-64.so.2
#4 0x779b42ac in ?? () from /lib/libdl.so.2
#5 0x779b407a in dlsym () from /lib/libdl.so.2
#6 0x00499963 in
DYNLIBS_GETPROCEDUREADDRESS$INT64$ANSISTRING$$POINTER ()
#7 0x00493acd in GETPROCADDRESS (MODULE=-134393856,
PROC=0x6bfcf8 "SSL_get_error") at src/synafpc.pas:106
#8 0x00487beb in GETPROCADDR (MODULE=-134393856,
PROCNAME=0x6bfcf8 "SSL_get_error") at src/ssl_openssl_lib.pas:1688
#9 0x00487cec in INITSSLINTERFACE () at src/ssl_openssl_lib.pas:1715
#10 0x00433d41 in SSL_OPENSSL_init () at src/ssl_openssl.pas:818
#11 0x0042478e in fpc_initializeunits ()
#12 0x in ?? ()
(gdb) info reg
rax0xf7fd5388 -134392952
rbx0x7f44c24c94e941a0 9170668375404790176
rcx0x77fe92dd 140737354044125
rdx0x433ee85ef9908c1f 4845565743708802079
rsi0xf7fd5000 -134393856
rdi0x77fe92d0 140737354044112
rbp0x7fffdc50 0x7fffdc50
rsp0x7fffdb30 0x7fffdb30
r8 0x 4294967295
r9 0x0 0
r100x7fffdb00 140737488345856
r110x76f5f3
[fpc-pascal] Re: access violation somehow related to dlopen'ing libssl
Whoa... I discovered that simply adding "dynlibs" to the interface uses clause of ssl_openssl_lib causes the crash to go away and everything to work fine. After further experimentation, if I put "dynlibs" in the uses clause of ssl_openssl_lib prior to "Classes", it still crashes. If I add it after "Classes", the crash goes away. Not sure what that means... -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: access violation somehow related to dlopen'ing libssl
On Fri, 2 Jul 2010, Seth Grover wrote: Whoa... I discovered that simply adding "dynlibs" to the interface uses clause of ssl_openssl_lib causes the crash to go away and everything to work fine. After further experimentation, if I put "dynlibs" in the uses clause of ssl_openssl_lib prior to "Classes", it still crashes. If I add it after "Classes", the crash goes away. Not sure what that means... If 'sysutils' is somewhere included (I assume it is) it means that a different loadlibrary function is called. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] How to include a Windows Version resource in a fpc compiled DLL?
I have recently ported over a DLL from Delphi to fpc, so we can offer the DLL as a shared library on 32/64 bit linux, as well as 64-bit Windows. On the Windows platform, version information is often included as a resource which can be queried & displayed. Is there any way to include this information in the 64-bit fpc compiled DLL? Thanks much, Alan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to include a Windows Version resource in a fpc compiled DLL?
02.07.2010 23:29, Alan Krause wrote: On the Windows platform, version information is often included as a resource which can be queried & displayed. Is there any way to include this information in the 64-bit fpc compiled DLL? Use Lazarus IDE for editing you dll project. You can set the version information in it and Lazarus create a res file for you. Best regards, Paul Ishenin. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to include a Windows Version resource in a fpc compiled DLL?
Paul, I don't use lazarus, and am trying to automate the entire build and release cycle for the different platforms. Can you provide me with a sample that can be compiled from the command line, or point me towards the appropriate documentation? Thanks much, Alan On Fri, Jul 2, 2010 at 8:34 AM, Paul Ishenin wrote: > 02.07.2010 23:29, Alan Krause wrote: > >> On the Windows platform, version information is often included as a >> resource which can be queried & displayed. Is there any way to include this >> information in the 64-bit fpc compiled DLL? >> > Use Lazarus IDE for editing you dll project. You can set the version > information in it and Lazarus create a res file for you. > > Best regards, > Paul Ishenin. > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to include a Windows Version resource in a fpc compiled DLL?
02.07.2010 23:44, Alan Krause wrote:
I don't use lazarus, and am trying to automate the entire build and
release cycle for the different platforms.
You don't need to use it for every build. Just once to create the res
file with version information. If you include that res file into your
project {$R myres.res} you will have a dll with the version information.
Best regards,
Paul Ishenin.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: access violation somehow related to dlopen'ing libssl
Michael wrote: > If 'sysutils' is somewhere included (I assume it is) it means that a > different loadlibrary function is called. Thanks for the response. Actually, I saved the assembly code generated from both ways and compared them and realized the problem was with the definition of HModule. classesh.inc has: HMODULE = longint; and dynlibs.pas has: HModule = TLibHandle; If the classes one gets used, it crashes. Anyway, I know what to do now. Thanks, -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Working Free Pascal android JNI example
Am 02.07.2010 02:11, schrieb Reimar Grabowski: From your mail it is not clear which ld and as you used. I just took them from the Android NDK, you too? Unfortunately I currently have no time to play around with your code, but I will as soon as I can. Under linux I'm using self-built arm binutils, and under windows I'm using the YAGARTO "Yet another GNU ARM toolchain", because the original android NDK ARM binutils binaries are very buggy, at least the ld linker from it. Did you try if gdb and gprof are working? So far when I had time for this :-) All in all great work and perhaps you can claim the bounty: http://wiki.lazarus.freepascal.org/Bounties#Cross-Compile_to_Android_on_Ubuntu_X64 My compiler runs on Ubuntu64, so yours should too and with JNI you are able to build real .apks which I think is good enough to claim the bounty. A lazarus android UI widget set is so far very difficult to make for now, because android's UI concept is very different from another UI concepts and therefore very difficult to adapt this concept for the LCL "in the current state". But a alternative way would be the way over a own OpenGL ES based GUI engine for android lazarus apps, but that would break the android UI design concept philosophy. Short: My android JNI freepascal stuff is rather only for to speedup some things, for example DSP audio stuff, game rendering/complexlogic code, etc. all what will be as Java code a lot of slower than freepascal native code, but not for android UI things, sorry. But Lazarus extending with a plain android JNI features (with automatic injecting into a "host Java JNI caller stub" apk and apk resigning) will be perharps posssible (for example for freepascal-based Android OpenGL ES games and so on, where no native android UI stuff is needed). Benjamin 'BeRo' Rosseaux ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
