httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Lewis <...@joe-lewis.com>
Subject Re: Followup to earlier thread about "How to compiling/link/use Apache module that uses shared library?"
Date Fri, 22 Jun 2012 16:22:30 GMT
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/

Mime
View raw message