You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modules-dev@httpd.apache.org by oh...@cox.net on 2012/06/22 17:32:45 UTC
Followup to earlier thread about "How to compiling/link/use Apache
module that uses shared library?"
Hi,
Now that I've gotten by earlier problems with the module I'm working on (see thread "Re: UNSOLVED was Re: SOLVED was Re: How to compiling/link/use Apache module that uses shared library?"), I am trying to get my module to work with the stuff in that libobaccess.so. This .so is part of Oracle's Access Server SDK (ASDK).
The problem I'm running into now is that there's an initialization call in the library that I need to make, ObConfig_initialize() that is suppose to initialize the SDK environment, but when I call that (it takes either NULL or a const * char as parameter), it's blowing up (Apache aborts).
I *think* that the problem is that the libobaccess.so is actually C++, with a bunch of wrapper-type C functions to wrap the C++ functions, i.e., so my module (which is C) calls a function, and inside obaccess.so the function calls a C++ function)., and it's probably blowing up because the Oracle code doesn't know anything about Pool memory, but rather uses C++ new, etc.
Here's a gdb backtrace showing this:
In callAccessGate()...
In callAccessGate(): About to set handler...
In callAccessGate(): returned from set handler
In callAccessGate(): About to call ObConfig_initialize()...
Program received signal SIGABRT, Aborted.
[Switching to Thread 182897612000 (LWP 15573)]
0x000000351432e26d in raise () from /lib64/tls/libc.so.6
(gdb) bt full
#0 0x000000351432e26d in raise () from /lib64/tls/libc.so.6
No symbol table info available.
#1 0x000000351432fa6e in abort () from /lib64/tls/libc.so.6
No symbol table info available.
#2 0x000000351a7b1148 in __gnu_cxx::__verbose_terminate_handler () from /lib64/libstdc++.so.6
No symbol table info available.
#3 0x000000351a7af176 in __cxa_call_unexpected () from /lib64/libstdc++.so.6
No symbol table info available.
#4 0x000000351a7af1a3 in std::terminate () from /lib64/libstdc++.so.6
No symbol table info available.
#5 0x000000351a7af2a3 in __cxa_throw () from /lib64/libstdc++.so.6
No symbol table info available.
#6 0x0000002a97898a05 in ObThreadInitNLS () from /apps/netpoint/lib64/libobaccess.so
No symbol table info available.
#7 0x0000002a97898f75 in SetGlobalInTLS () from /apps/netpoint/lib64/libobaccess.so
No symbol table info available.
#8 0x0000002a9789913f in GetGlobalFromTLS () from /apps/netpoint/lib64/libobaccess.so
No symbol table info available.
#9 0x0000002a97899edc in NLS::NLS () from /apps/netpoint/lib64/libobaccess.so
No symbol table info available.
#10 0x0000002a9773f1b1 in ObConfig::initialize () from /apps/netpoint/lib64/libobaccess.so
No symbol table info available.
#11 0x0000002a976ee55d in ObConfig_initialize () from /apps/netpoint/lib64/libobaccess.so
---Type <return> to continue, or q <return> to quit---
No symbol table info available.
#12 0x0000002a97b94266 in callAccessGate (
PEM=0x706850 "MIICrTCCAhagAwIBAgICECUwDQYJKoZIhvcNAQEEBQAwgZMxCzAJBgNVBAYTAlVT\nMQswCQYDVQQIEwJWQTEPMA0GA1UEBxMGT0FLVE9OMRMwEQYDVQQKEwpKTFNpbXBs\nZUNBMRIwEAYDVQQLEwlKTERlbW8gQ0ExGzAZBgNVBAMTEkpMU2ltcGxlQ0EgRGVt\nbyBDQ"...,
url=0x2a97b956b0 "//apache1/certprotected/index.html") at mod_headers.c:847
res = Variable "res" is not available.
(gdb)
So, my code calls ObConfig_initialize() then it appears that that calls ObConfig_initialize() which is presumably a C++ function.
In general, is there any way to handle this problem/situation if it's memory allocation (inside libobaccess.so) related?
Thanks,
Jim
Re: Followup to earlier thread about "How to compiling/link/use
Apache module that uses shared library?"
Posted by oh...@cox.net.
---- Joe Lewis <jo...@joe-lewis.com> wrote:
> On 6/22/12 9:35 AM, ohaya@cox.net wrote:
> > ---- ohaya@cox.net wrote:
> >> Hi,
> >>
> >> Now that I've gotten by earlier problems with the module I'm working on (see thread "Re: UNSOLVED was Re: SOLVED was Re: How to compiling/link/use Apache module that uses shared library?"), I am trying to get my module to work with the stuff in that libobaccess.so. This .so is part of Oracle's Access Server SDK (ASDK).
> >>
> >> The problem I'm running into now is that there's an initialization call in the library that I need to make, ObConfig_initialize() that is suppose to initialize the SDK environment, but when I call that (it takes either NULL or a const * char as parameter), it's blowing up (Apache aborts).
> >>
> >> I *think* that the problem is that the libobaccess.so is actually C++, with a bunch of wrapper-type C functions to wrap the C++ functions, i.e., so my module (which is C) calls a function, and inside obaccess.so the function calls a C++ function)., and it's probably blowing up because the Oracle code doesn't know anything about Pool memory, but rather uses C++ new, etc.
> >>
> >> Here's a gdb backtrace showing this:
> >>
> >> In callAccessGate()...
> >>
> >>
> >> In callAccessGate(): About to set handler...
> >>
> >> In callAccessGate(): returned from set handler
> >>
> >>
> >> In callAccessGate(): About to call ObConfig_initialize()...
> >>
> >> Program received signal SIGABRT, Aborted.
> >> [Switching to Thread 182897612000 (LWP 15573)]
> >> 0x000000351432e26d in raise () from /lib64/tls/libc.so.6
> >> (gdb) bt full
> >> #0 0x000000351432e26d in raise () from /lib64/tls/libc.so.6
> >> No symbol table info available.
> >> #1 0x000000351432fa6e in abort () from /lib64/tls/libc.so.6
> >> No symbol table info available.
> >> #2 0x000000351a7b1148 in __gnu_cxx::__verbose_terminate_handler () from /lib64/libstdc++.so.6
> >> No symbol table info available.
> >> #3 0x000000351a7af176 in __cxa_call_unexpected () from /lib64/libstdc++.so.6
> >> No symbol table info available.
> >> #4 0x000000351a7af1a3 in std::terminate () from /lib64/libstdc++.so.6
> >> No symbol table info available.
> >> #5 0x000000351a7af2a3 in __cxa_throw () from /lib64/libstdc++.so.6
> >> No symbol table info available.
> >> #6 0x0000002a97898a05 in ObThreadInitNLS () from /apps/netpoint/lib64/libobaccess.so
> >> No symbol table info available.
> >> #7 0x0000002a97898f75 in SetGlobalInTLS () from /apps/netpoint/lib64/libobaccess.so
> >> No symbol table info available.
> >> #8 0x0000002a9789913f in GetGlobalFromTLS () from /apps/netpoint/lib64/libobaccess.so
> >> No symbol table info available.
> >> #9 0x0000002a97899edc in NLS::NLS () from /apps/netpoint/lib64/libobaccess.so
> >> No symbol table info available.
> >> #10 0x0000002a9773f1b1 in ObConfig::initialize () from /apps/netpoint/lib64/libobaccess.so
> >> No symbol table info available.
> >> #11 0x0000002a976ee55d in ObConfig_initialize () from /apps/netpoint/lib64/libobaccess.so
> >> ---Type<return> to continue, or q<return> to quit---
> >> No symbol table info available.
> >> #12 0x0000002a97b94266 in callAccessGate (
> >> PEM=0x706850 "MIICrTCCAhagAwIBAgICECUwDQYJKoZIhvcNAQEEBQAwgZMxCzAJBgNVBAYTAlVT\nMQswCQYDVQQIEwJWQTEPMA0GA1UEBxMGT0FLVE9OMRMwEQYDVQQKEwpKTFNpbXBs\nZUNBMRIwEAYDVQQLEwlKTERlbW8gQ0ExGzAZBgNVBAMTEkpMU2ltcGxlQ0EgRGVt\nbyBDQ"...,
> >> url=0x2a97b956b0 "//apache1/certprotected/index.html") at mod_headers.c:847
> >> res = Variable "res" is not available.
> >> (gdb)
> >>
> >> So, my code calls ObConfig_initialize() then it appears that that calls ObConfig_initialize() which is presumably a C++ function.
> >>
> >> In general, is there any way to handle this problem/situation if it's memory allocation (inside libobaccess.so) related?
> >>
> >> Thanks,
> >> Jim
> > Sorry. I meant to say:
> >
> > "So, my code calls ObConfig_initialize() then it appears that that calls
> > ObConfig::initialize() which is presumably a C++ function. "
> >
> > Jim
>
> I believe you are correct - the previous stack traces (exception
> handling) is a C++ thing. The real problem you have is that it's using
> malloc() and free(), and I don't think you can manipulate that. You may
> have to contact Oracle to see if there are functions to override their
> use of malloc and free. If there's not a way to override, you have one
> option - on post_config, spin off a separate process that you
> communicate with via socket/IPC.
>
> Joe
> --
> http://www.silverhawk.net/
Hi Joe,
Thanks for that info, and yes, I've opened up an SR (case) with Oracle, but I have the feeling, based on previous situations, that they're not going to be amenable to do anything, because that ASDK is an older one that they don't support (their newer one is pure Java).
I was mainly interested if there was a generic way to handle this type of situation.
I had already been thinking about something similar to what you suggested, something like hosting a JSP on a Tomcat somewhere, and that JSP would call the Oracle API, and then having my module have a connection to the Tomcat to get what it needs.
Pretty convoluted though...
Thanks again,
Jim
Re: Followup to earlier thread about "How to compiling/link/use Apache
module that uses shared library?"
Posted by Joe Lewis <jo...@joe-lewis.com>.
On 6/22/12 9:35 AM, ohaya@cox.net wrote:
> ---- ohaya@cox.net wrote:
>> Hi,
>>
>> Now that I've gotten by earlier problems with the module I'm working on (see thread "Re: UNSOLVED was Re: SOLVED was Re: How to compiling/link/use Apache module that uses shared library?"), I am trying to get my module to work with the stuff in that libobaccess.so. This .so is part of Oracle's Access Server SDK (ASDK).
>>
>> The problem I'm running into now is that there's an initialization call in the library that I need to make, ObConfig_initialize() that is suppose to initialize the SDK environment, but when I call that (it takes either NULL or a const * char as parameter), it's blowing up (Apache aborts).
>>
>> I *think* that the problem is that the libobaccess.so is actually C++, with a bunch of wrapper-type C functions to wrap the C++ functions, i.e., so my module (which is C) calls a function, and inside obaccess.so the function calls a C++ function)., and it's probably blowing up because the Oracle code doesn't know anything about Pool memory, but rather uses C++ new, etc.
>>
>> Here's a gdb backtrace showing this:
>>
>> In callAccessGate()...
>>
>>
>> In callAccessGate(): About to set handler...
>>
>> In callAccessGate(): returned from set handler
>>
>>
>> In callAccessGate(): About to call ObConfig_initialize()...
>>
>> Program received signal SIGABRT, Aborted.
>> [Switching to Thread 182897612000 (LWP 15573)]
>> 0x000000351432e26d in raise () from /lib64/tls/libc.so.6
>> (gdb) bt full
>> #0 0x000000351432e26d in raise () from /lib64/tls/libc.so.6
>> No symbol table info available.
>> #1 0x000000351432fa6e in abort () from /lib64/tls/libc.so.6
>> No symbol table info available.
>> #2 0x000000351a7b1148 in __gnu_cxx::__verbose_terminate_handler () from /lib64/libstdc++.so.6
>> No symbol table info available.
>> #3 0x000000351a7af176 in __cxa_call_unexpected () from /lib64/libstdc++.so.6
>> No symbol table info available.
>> #4 0x000000351a7af1a3 in std::terminate () from /lib64/libstdc++.so.6
>> No symbol table info available.
>> #5 0x000000351a7af2a3 in __cxa_throw () from /lib64/libstdc++.so.6
>> No symbol table info available.
>> #6 0x0000002a97898a05 in ObThreadInitNLS () from /apps/netpoint/lib64/libobaccess.so
>> No symbol table info available.
>> #7 0x0000002a97898f75 in SetGlobalInTLS () from /apps/netpoint/lib64/libobaccess.so
>> No symbol table info available.
>> #8 0x0000002a9789913f in GetGlobalFromTLS () from /apps/netpoint/lib64/libobaccess.so
>> No symbol table info available.
>> #9 0x0000002a97899edc in NLS::NLS () from /apps/netpoint/lib64/libobaccess.so
>> No symbol table info available.
>> #10 0x0000002a9773f1b1 in ObConfig::initialize () from /apps/netpoint/lib64/libobaccess.so
>> No symbol table info available.
>> #11 0x0000002a976ee55d in ObConfig_initialize () from /apps/netpoint/lib64/libobaccess.so
>> ---Type<return> to continue, or q<return> to quit---
>> No symbol table info available.
>> #12 0x0000002a97b94266 in callAccessGate (
>> PEM=0x706850 "MIICrTCCAhagAwIBAgICECUwDQYJKoZIhvcNAQEEBQAwgZMxCzAJBgNVBAYTAlVT\nMQswCQYDVQQIEwJWQTEPMA0GA1UEBxMGT0FLVE9OMRMwEQYDVQQKEwpKTFNpbXBs\nZUNBMRIwEAYDVQQLEwlKTERlbW8gQ0ExGzAZBgNVBAMTEkpMU2ltcGxlQ0EgRGVt\nbyBDQ"...,
>> url=0x2a97b956b0 "//apache1/certprotected/index.html") at mod_headers.c:847
>> res = Variable "res" is not available.
>> (gdb)
>>
>> So, my code calls ObConfig_initialize() then it appears that that calls ObConfig_initialize() which is presumably a C++ function.
>>
>> In general, is there any way to handle this problem/situation if it's memory allocation (inside libobaccess.so) related?
>>
>> Thanks,
>> Jim
> Sorry. I meant to say:
>
> "So, my code calls ObConfig_initialize() then it appears that that calls
> ObConfig::initialize() which is presumably a C++ function. "
>
> Jim
I believe you are correct - the previous stack traces (exception
handling) is a C++ thing. The real problem you have is that it's using
malloc() and free(), and I don't think you can manipulate that. You may
have to contact Oracle to see if there are functions to override their
use of malloc and free. If there's not a way to override, you have one
option - on post_config, spin off a separate process that you
communicate with via socket/IPC.
Joe
--
http://www.silverhawk.net/
Re: Followup to earlier thread about "How to compiling/link/use
Apache module that uses shared library?"
Posted by oh...@cox.net.
---- Sorin Manolache <so...@gmail.com> wrote:
> On 2012-06-22 21:22, ohaya@cox.net wrote:
> >
> > Does that confirm that they statically linked stuff from openssl (and libcrypto) into libobaccess.so?
>
> I think so.
>
> Also you can run nm -aC liboaccess.so. The symbols marked with "U" are
> undefined => they are external to the lib. The functions marked with "T"
> or "t" are defined by the lib => their code is in the binary.
>
> Functions marked with upper-case ("T") are exported, i.e. another module
> may use the function. Functions marked with lower-case ("t") are not
> exported. Those functions can be run by other functions in the same
> module only. If the libcrypto functions in liboaccess were not exported
> (marked with lower-case letter) you wouldn't have a problem: the
> functions in liboaccess would execute the libcrypto functions in
> liboaccess and the functions in mod_ssl would execute the libcrypto
> functions in your system's libcrypto.
>
> But I suppose that's not the case.
>
> > Assuming that's the case, is there any way around this?
>
> The easiest way would be to have a liboaccess _dynamically_ linked with
> libcrypto. In this case, the first module between mod_ssl and your
> module that loads would load libcrypto. When the second module loads,
> the loader tries to resolve the undefined symbols of the second module
> and it will find them in the already loaded libcrypto.
>
> If you cannot obtain a liboaccess dynamically linked with libcrypto, you
> _could_ try to recompile mod_ssl such that it does not export any
> libcrypto functions, but I don't know if it is possible.
>
> S
Hi,
There're a bunch of "X509_" symbols. Most/all of those are marked "T", including "X509_free".
There're a bunch of "bn_" symbols. Some are marked "T", but most of them are "a" or "t" (local).
I'm still working the case with Oracle, but am not sure where they'll go with that.
Thanks,
Jim
Re: Followup to earlier thread about "How to compiling/link/use Apache
module that uses shared library?"
Posted by Sorin Manolache <so...@gmail.com>.
On 2012-06-22 21:22, ohaya@cox.net wrote:
>
> Does that confirm that they statically linked stuff from openssl (and libcrypto) into libobaccess.so?
I think so.
Also you can run nm -aC liboaccess.so. The symbols marked with "U" are
undefined => they are external to the lib. The functions marked with "T"
or "t" are defined by the lib => their code is in the binary.
Functions marked with upper-case ("T") are exported, i.e. another module
may use the function. Functions marked with lower-case ("t") are not
exported. Those functions can be run by other functions in the same
module only. If the libcrypto functions in liboaccess were not exported
(marked with lower-case letter) you wouldn't have a problem: the
functions in liboaccess would execute the libcrypto functions in
liboaccess and the functions in mod_ssl would execute the libcrypto
functions in your system's libcrypto.
But I suppose that's not the case.
> Assuming that's the case, is there any way around this?
The easiest way would be to have a liboaccess _dynamically_ linked with
libcrypto. In this case, the first module between mod_ssl and your
module that loads would load libcrypto. When the second module loads,
the loader tries to resolve the undefined symbols of the second module
and it will find them in the already loaded libcrypto.
If you cannot obtain a liboaccess dynamically linked with libcrypto, you
_could_ try to recompile mod_ssl such that it does not export any
libcrypto functions, but I don't know if it is possible.
S
Re: Followup to earlier thread about "How to compiling/link/use
Apache module that uses shared library?"
Posted by oh...@cox.net.
---- ohaya@cox.net wrote:
>
> ---- ohaya@cox.net wrote:
> >
> > ---- Sorin Manolache <so...@gmail.com> wrote:
> > > On 2012-06-22 17:35, ohaya@cox.net wrote:
> > >
> > > >
> > > > Sorry. I meant to say:
> > > >
> > > > "So, my code calls ObConfig_initialize() then it appears that that calls
> > > > ObConfig::initialize() which is presumably a C++ function. "
> > > >
> > >
> > > We develop our apache modules in C++ on a regular basis and they
> > > interact with other modules written in plain C and there's no problem.
> > >
> > > What I think happens in your case is:
> > >
> > > I suspect that the Oracle lib was _statically_ linked with libcrypto. So
> > > the code of some version of libcrypto is in the libobaccess binary. Then
> > > mod_ssl is _dynamically_ linked with libcrypto. I suspect that the two
> > > libcryptos have different versions and they are possibly incompatible =>
> > > segfaults at all kind of mallocs/frees. I think it has nothing to do
> > > with new/delete vs malloc/free.
> > >
> > > S
> >
> >
> > Hi,
> >
> > How can I determine whether the libobaccess.so was statically linked with libcrypto?
> >
> > Also, I'll check again, but I think that I checked before using ldd, and both obaccess.so and mod_ssl.so were pointing to the same libcrypto.
> >
> > Jim
>
> Hi,
>
> Sorry, I got confused.
>
> [root@apachemodule ~]# ldd /apps/httpd2222/modules/mod_ssl.so
> libssl.so.4 => /lib64/libssl.so.4 (0x0000002a95697000)
> libcrypto.so.4 => /lib64/libcrypto.so.4 (0x0000002a957d4000)
> libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x0000002a95a05000)
> libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x0000002a95b1b000)
> libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0000002a95c8d000)
> libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x0000002a95d8f000)
> libdl.so.2 => /lib64/libdl.so.2 (0x0000002a95eb2000)
> libz.so.1 => /usr/lib64/libz.so.1 (0x0000002a95fb6000)
> libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x0000002a960c9000)
> libc.so.6 => /lib64/tls/libc.so.6 (0x0000002a961de000)
> libresolv.so.2 => /lib64/libresolv.so.2 (0x0000002a96418000)
> /lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000)
> [root@apachemodule ~]#
> [root@apachemodule ~]#
> [root@apachemodule ~]# ldd /apps/netpoint/lib64/libobaccess.so
> libnsl.so.1 => /lib64/libnsl.so.1 (0x0000002a95ab8000)
> libdl.so.2 => /lib64/libdl.so.2 (0x0000002a95bd0000)
> libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x0000002a95cd3000)
> libstdc++.so.6 => /lib64/libstdc++.so.6 (0x0000002a95de9000)
> libm.so.6 => /lib64/tls/libm.so.6 (0x0000002a95fd9000)
> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000002a9615f000)
> libc.so.6 => /lib64/tls/libc.so.6 (0x0000002a9626d000)
> /lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000)
>
> Only mod_ssl.so is showing pointer to libcrypto.
>
> Is there a way to determine if libobaccess.so is linked statically to libcrypto, and now showing up in the ldd?
>
> Jim
>
Hi,
I found this:
http://stackoverflow.com/questions/4925012/can-i-get-a-report-of-all-the-libraries-linked-when-building-my-c-executable
When I run:
objdump -t /apps/netpoint/lib64/libobaccess.so | grep "ABS"
I get a bunch of stuff, including a bunch of "x509_xxx.c", e.g.:
[root@apachemodule ~]# objdump -t /apps/netpoint/lib64/libobaccess.so | grep "ABS" | grep "x509"
0000000000000000 l df *ABS* 0000000000000000 x509_fnc.c
0000000000000000 l df *ABS* 0000000000000000 x509_fnc.c
0000000000000000 l df *ABS* 0000000000000000 x_x509.c
0000000000000000 l df *ABS* 0000000000000000 x509_d2.c
0000000000000000 l df *ABS* 0000000000000000 x509_err.c
0000000000000000 l df *ABS* 0000000000000000 x509_vfy.c
0000000000000000 l df *ABS* 0000000000000000 x509_obj.c
0000000000000000 l df *ABS* 0000000000000000 x509name.c
0000000000000000 l df *ABS* 0000000000000000 x509type.c
0000000000000000 l df *ABS* 0000000000000000 x509_lu.c
0000000000000000 l df *ABS* 0000000000000000 x509_lu.c
0000000000000000 l df *ABS* 0000000000000000 x509_lu.c
0000000000000000 l df *ABS* 0000000000000000 x509_lu.c
0000000000000000 l df *ABS* 0000000000000000 x509_fnc.c
0000000000000000 l df *ABS* 0000000000000000 x509_fnc.c
0000000000000000 l df *ABS* 0000000000000000 x509_fnc.c
0000000000000000 l df *ABS* 0000000000000000 x509_fnc.c
0000000000000000 l df *ABS* 0000000000000000 x509_st.c
0000000000000000 l df *ABS* 0000000000000000 x509_st.c
0000000000000000 l df *ABS* 0000000000000000 x509_st.c
0000000000000000 l df *ABS* 0000000000000000 x509_st.c
0000000000000000 l df *ABS* 0000000000000000 x509_st.c
0000000000000000 l df *ABS* 0000000000000000 x509_st.c
0000000000000000 l df *ABS* 0000000000000000 x509_st.c
0000000000000000 l df *ABS* 0000000000000000 x509_st.c
0000000000000000 l df *ABS* 0000000000000000 x509_st.c
0000000000000000 l df *ABS* 0000000000000000 x509_st.c
0000000000000000 l df *ABS* 0000000000000000 x509_cmp.c
0000000000000000 l df *ABS* 0000000000000000 x509_cmp.c
0000000000000000 l df *ABS* 0000000000000000 x509_cmp.c
0000000000000000 l df *ABS* 0000000000000000 x509_cmp.c
0000000000000000 l df *ABS* 0000000000000000 x509_cmp.c
0000000000000000 l df *ABS* 0000000000000000 x509_cmp.c
0000000000000000 l df *ABS* 0000000000000000 x509_cmp.c
0000000000000000 l df *ABS* 0000000000000000 x509_cmp.c
0000000000000000 l df *ABS* 0000000000000000 x509_lu2.c
0000000000000000 l df *ABS* 0000000000000000 x509_lu2.c
0000000000000000 l df *ABS* 0000000000000000 x509_def.c
0000000000000000 l df *ABS* 0000000000000000 x509_v3.c
0000000000000000 l df *ABS* 0000000000000000 x509_cct.c
0000000000000000 l df *ABS* 0000000000000000 x509_gpp.c
0000000000000000 l df *ABS* 0000000000000000 x509_ext.c
0000000000000000 l df *ABS* 0000000000000000 x509_ext.c
0000000000000000 l df *ABS* 0000000000000000 x509_lu.c
0000000000000000 l df *ABS* 0000000000000000 x509_lu.c
0000000000000000 l df *ABS* 0000000000000000 x509_lu.c
0000000000000000 l df *ABS* 0000000000000000 x509_lu.c
[root@apachemodule ~]#
I just picked on, "x509_lu.c" and googled and that looks like it's part of openssl:
http://www.polarhome.com/cvs/CVSROOT/openssl/crypto/x509/x509_lu.c
Does that confirm that they statically linked stuff from openssl (and libcrypto) into libobaccess.so?
Assuming that's the case, is there any way around this?
Thanks,
Jim
Re: Followup to earlier thread about "How to compiling/link/use
Apache module that uses shared library?"
Posted by oh...@cox.net.
---- ohaya@cox.net wrote:
>
> ---- Sorin Manolache <so...@gmail.com> wrote:
> > On 2012-06-22 17:35, ohaya@cox.net wrote:
> >
> > >
> > > Sorry. I meant to say:
> > >
> > > "So, my code calls ObConfig_initialize() then it appears that that calls
> > > ObConfig::initialize() which is presumably a C++ function. "
> > >
> >
> > We develop our apache modules in C++ on a regular basis and they
> > interact with other modules written in plain C and there's no problem.
> >
> > What I think happens in your case is:
> >
> > I suspect that the Oracle lib was _statically_ linked with libcrypto. So
> > the code of some version of libcrypto is in the libobaccess binary. Then
> > mod_ssl is _dynamically_ linked with libcrypto. I suspect that the two
> > libcryptos have different versions and they are possibly incompatible =>
> > segfaults at all kind of mallocs/frees. I think it has nothing to do
> > with new/delete vs malloc/free.
> >
> > S
>
>
> Hi,
>
> How can I determine whether the libobaccess.so was statically linked with libcrypto?
>
> Also, I'll check again, but I think that I checked before using ldd, and both obaccess.so and mod_ssl.so were pointing to the same libcrypto.
>
> Jim
Hi,
Sorry, I got confused.
[root@apachemodule ~]# ldd /apps/httpd2222/modules/mod_ssl.so
libssl.so.4 => /lib64/libssl.so.4 (0x0000002a95697000)
libcrypto.so.4 => /lib64/libcrypto.so.4 (0x0000002a957d4000)
libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x0000002a95a05000)
libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x0000002a95b1b000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0000002a95c8d000)
libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x0000002a95d8f000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000002a95eb2000)
libz.so.1 => /usr/lib64/libz.so.1 (0x0000002a95fb6000)
libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x0000002a960c9000)
libc.so.6 => /lib64/tls/libc.so.6 (0x0000002a961de000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x0000002a96418000)
/lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000)
[root@apachemodule ~]#
[root@apachemodule ~]#
[root@apachemodule ~]# ldd /apps/netpoint/lib64/libobaccess.so
libnsl.so.1 => /lib64/libnsl.so.1 (0x0000002a95ab8000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000002a95bd0000)
libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x0000002a95cd3000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x0000002a95de9000)
libm.so.6 => /lib64/tls/libm.so.6 (0x0000002a95fd9000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000002a9615f000)
libc.so.6 => /lib64/tls/libc.so.6 (0x0000002a9626d000)
/lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000)
Only mod_ssl.so is showing pointer to libcrypto.
Is there a way to determine if libobaccess.so is linked statically to libcrypto, and now showing up in the ldd?
Jim
Re: Followup to earlier thread about "How to compiling/link/use
Apache module that uses shared library?"
Posted by oh...@cox.net.
---- Sorin Manolache <so...@gmail.com> wrote:
> On 2012-06-22 17:35, ohaya@cox.net wrote:
>
> >
> > Sorry. I meant to say:
> >
> > "So, my code calls ObConfig_initialize() then it appears that that calls
> > ObConfig::initialize() which is presumably a C++ function. "
> >
>
> We develop our apache modules in C++ on a regular basis and they
> interact with other modules written in plain C and there's no problem.
>
> What I think happens in your case is:
>
> I suspect that the Oracle lib was _statically_ linked with libcrypto. So
> the code of some version of libcrypto is in the libobaccess binary. Then
> mod_ssl is _dynamically_ linked with libcrypto. I suspect that the two
> libcryptos have different versions and they are possibly incompatible =>
> segfaults at all kind of mallocs/frees. I think it has nothing to do
> with new/delete vs malloc/free.
>
> S
Hi,
How can I determine whether the libobaccess.so was statically linked with libcrypto?
Also, I'll check again, but I think that I checked before using ldd, and both obaccess.so and mod_ssl.so were pointing to the same libcrypto.
Jim
Re: Followup to earlier thread about "How to compiling/link/use Apache
module that uses shared library?"
Posted by Sorin Manolache <so...@gmail.com>.
On 2012-06-22 17:35, ohaya@cox.net wrote:
>
> Sorry. I meant to say:
>
> "So, my code calls ObConfig_initialize() then it appears that that calls
> ObConfig::initialize() which is presumably a C++ function. "
>
We develop our apache modules in C++ on a regular basis and they
interact with other modules written in plain C and there's no problem.
What I think happens in your case is:
I suspect that the Oracle lib was _statically_ linked with libcrypto. So
the code of some version of libcrypto is in the libobaccess binary. Then
mod_ssl is _dynamically_ linked with libcrypto. I suspect that the two
libcryptos have different versions and they are possibly incompatible =>
segfaults at all kind of mallocs/frees. I think it has nothing to do
with new/delete vs malloc/free.
S
Re: Followup to earlier thread about "How to compiling/link/use
Apache module that uses shared library?"
Posted by oh...@cox.net.
---- ohaya@cox.net wrote:
> Hi,
>
> Now that I've gotten by earlier problems with the module I'm working on (see thread "Re: UNSOLVED was Re: SOLVED was Re: How to compiling/link/use Apache module that uses shared library?"), I am trying to get my module to work with the stuff in that libobaccess.so. This .so is part of Oracle's Access Server SDK (ASDK).
>
> The problem I'm running into now is that there's an initialization call in the library that I need to make, ObConfig_initialize() that is suppose to initialize the SDK environment, but when I call that (it takes either NULL or a const * char as parameter), it's blowing up (Apache aborts).
>
> I *think* that the problem is that the libobaccess.so is actually C++, with a bunch of wrapper-type C functions to wrap the C++ functions, i.e., so my module (which is C) calls a function, and inside obaccess.so the function calls a C++ function)., and it's probably blowing up because the Oracle code doesn't know anything about Pool memory, but rather uses C++ new, etc.
>
> Here's a gdb backtrace showing this:
>
> In callAccessGate()...
>
>
> In callAccessGate(): About to set handler...
>
> In callAccessGate(): returned from set handler
>
>
> In callAccessGate(): About to call ObConfig_initialize()...
>
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 182897612000 (LWP 15573)]
> 0x000000351432e26d in raise () from /lib64/tls/libc.so.6
> (gdb) bt full
> #0 0x000000351432e26d in raise () from /lib64/tls/libc.so.6
> No symbol table info available.
> #1 0x000000351432fa6e in abort () from /lib64/tls/libc.so.6
> No symbol table info available.
> #2 0x000000351a7b1148 in __gnu_cxx::__verbose_terminate_handler () from /lib64/libstdc++.so.6
> No symbol table info available.
> #3 0x000000351a7af176 in __cxa_call_unexpected () from /lib64/libstdc++.so.6
> No symbol table info available.
> #4 0x000000351a7af1a3 in std::terminate () from /lib64/libstdc++.so.6
> No symbol table info available.
> #5 0x000000351a7af2a3 in __cxa_throw () from /lib64/libstdc++.so.6
> No symbol table info available.
> #6 0x0000002a97898a05 in ObThreadInitNLS () from /apps/netpoint/lib64/libobaccess.so
> No symbol table info available.
> #7 0x0000002a97898f75 in SetGlobalInTLS () from /apps/netpoint/lib64/libobaccess.so
> No symbol table info available.
> #8 0x0000002a9789913f in GetGlobalFromTLS () from /apps/netpoint/lib64/libobaccess.so
> No symbol table info available.
> #9 0x0000002a97899edc in NLS::NLS () from /apps/netpoint/lib64/libobaccess.so
> No symbol table info available.
> #10 0x0000002a9773f1b1 in ObConfig::initialize () from /apps/netpoint/lib64/libobaccess.so
> No symbol table info available.
> #11 0x0000002a976ee55d in ObConfig_initialize () from /apps/netpoint/lib64/libobaccess.so
> ---Type <return> to continue, or q <return> to quit---
> No symbol table info available.
> #12 0x0000002a97b94266 in callAccessGate (
> PEM=0x706850 "MIICrTCCAhagAwIBAgICECUwDQYJKoZIhvcNAQEEBQAwgZMxCzAJBgNVBAYTAlVT\nMQswCQYDVQQIEwJWQTEPMA0GA1UEBxMGT0FLVE9OMRMwEQYDVQQKEwpKTFNpbXBs\nZUNBMRIwEAYDVQQLEwlKTERlbW8gQ0ExGzAZBgNVBAMTEkpMU2ltcGxlQ0EgRGVt\nbyBDQ"...,
> url=0x2a97b956b0 "//apache1/certprotected/index.html") at mod_headers.c:847
> res = Variable "res" is not available.
> (gdb)
>
> So, my code calls ObConfig_initialize() then it appears that that calls ObConfig_initialize() which is presumably a C++ function.
>
> In general, is there any way to handle this problem/situation if it's memory allocation (inside libobaccess.so) related?
>
> Thanks,
> Jim
Sorry. I meant to say:
"So, my code calls ObConfig_initialize() then it appears that that calls
ObConfig::initialize() which is presumably a C++ function. "
Jim