Re: Seg Fault on program exit with OCI in shared library with dlopen() on Linux

OK. More info. If you use dlopen() to load a shared library that uses OCI, then you MUST NOT call dlclose() on that library. If you do, your program will seg fault while returning from main. If you omit the dlclose call, it will work fine. This is on Oracle 8.2.7.0.0.1 on linux.

I'm assuming that if I use this shared library in an external procedure that it will work. Has anyone sucessfully made an external procedure work under linux?

Thanks,

Mike

"Mike R. Prevost" <mprevost_at_gradkell.com> wrote in message news:0ZAH6.2547$c4.348497_at_e420r-chi1.usenetserver.com...
> I little more info on this. The function in which the seg violation
 is
> occuring (epc_exit_handler) is in the Oracle client libraries
> (libclntsh.so and libclntst.a).
>
>
>
> "Mike R. Prevost" <mprevost_at_gradkell.com> wrote in message
> news:XyzH6.2526$c4.339688_at_e420r-chi1.usenetserver.com...
> > I'm having a frustrating problem. I am writing a shared library
 that
 contains all my database logic. This library is dynamically
> > loaded at runtime via the dlopen()/dlsym() interface. I'm porting
 from a Win32 DLL to Linux and then to HP-UX.
> >
> > Everything works great with the shared library. I can link it in
 with
 a driver program at link time and all is well. However, when
> > I dynamically load it, the program seg faults when exiting. gdb
 tells
 me:
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x4036df9c in epc_exit_handler ()
> >
> > At first glance, this appears like some sort of stack corruption.
 It
 might be, but I don't think it is a result of my code because
> > it only happens when the OCI shared library is dynamically loaded.
 ALSO, I am able to dynamically load other shared libraries
> > without this problem.
> >
> > I'm made sure that the top level "driver" program is linked with
 libpthread. This evidently is a requirement when using OCI via
> > shared libraries. I've also tried linking the shared library
 against
 both libclntst8.a as well as libclntsh.so. Same story in both
> > cases.
> >
> > Has anyone run across this before?!?!
> >
> > Thanks.
> >
> > --- Mike R. Prevost
> > mprevost_at_gradkell.com
> >
> >
> >
> >
> >
> >
>
>
>
>
Received on Tue May 01 2001 - 17:59:40 CDT