This content has been marked as final. Show 13 replies
shared object that load into web server process spaceWhen you "inject" your shared object into some other process a well-being of your exception handling depends on that other process.
... same issue didn't observe if we make it as executable.
Mechanics of x64 stack traversing (unwind) performed when you throw the exception is quite complicated,
particularly involving a "nearly-standartized" Unwind interface (say, Unwind_RaiseException).
When we are talking about g++ on Solaris there are two implementations of unwind interface, one in libc and one in libgcc_s.so.
When you g++-compile the executable you get it directly linked with libgcc_s.so and Unwind stuff resolves into libgccs.
When g++-compiled shared object is loaded into non-g++-compiled executable's process _Unwind calls are most likely already resolved into Solaris libc.
Thats why you might see the difference.
Now, what exactly causes this difference can vary, I can only speculate.
All that would not be a problem if _Unwind interface was completely standartized and properly implemented.
However there are two issues currently:
* gcc (libstdc++ in particular) happens to use additional non-standard _Unwind calls which are not present in Solaris libc
naturally, implementation details of Unwind implementation in libc differs to that of libgccs, so when all the standard _Unwind
routines are resolved into Solaris version and one non-standard _Unwind routine is resolved into gcc version you get a problem
(most likely that is what happens with you)
* libc Unwind sometimes is unable to decipher the code generated by gcc.
However that is likely to happen with modern gcc (say, 4.4+) and not that likely with 3.4.3
Btw, you can check your call frame to see where _Unwind calls come from:
If you indeed stomped on "mixed _Unwind" problem then the only chance for you is to play with linker
where -h -l
so it binds Unwind stuff from your library directly into libgccs.
Not tried it myself though.
Thanks SFy for the reply. This is indeed my impression also. I confirmed same with -l option also.
 0x1116d(0x1, 0x1, 0x474e5543432b2b00, 0x59cb60, 0xfffffd7fffdff280, 0x1116d), at 0x1116d
 libc.so.1:_Unwind_RaiseException_Body(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff05b38c
 libc.so.1:_SUNW_Unwind_RaiseException(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff05b579 => libstdc++.so.6:__cxa_throw(obj = (nil), tinfo = (nil), dest = (nil), , line 75 in "eh_throw.cc"
 apache.so:OBWebGate_Init(p = 0x498188, plog = 0x4ca318, ptemp = 0x4cc328, s = 0x4c43c8), line 62 in "apache.cpp"
 httpd:ap_run_post_config(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x444624
 httpd:main(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x42c39a
I already tried many things to avoid libc dependency but didn't succeeded. Do you have any suggestion for it.
I confirmed same with -l optionwell, your stack trace does not show any signs of libgcc_s unwind, thus no signs of mixed interface usage.
however it might have happened before the crash.
Do you have any suggestion for it.You might want to experiment with Solaris linker's direct binding (http://download.oracle.com/docs/cd/E19963-01/html/819-0690/gehwq.html).
However the problem is that references to _Unwind are not only in your own code but also inside G++ STL (libstdc++).
Say, cxa_throw is what throws the exception, and it is a function from libstdc++.
You can try running your httpd with LD_PRELOAD=.../libgcc_s.so to see if it is really a culprit.
PRELOAD will have precedence over libc stuff.
That however might cause any unwinding in httpd itself broken (is it C++?).
We have tried with W,direct option also bit it did not help. With LD_preload, we are seeing issue. After setting LD_PRELOAD, we are getting ld error for libc.so.1.
Can anybody help us here.
After setting LD_PRELOAD, we are getting ld error for libc.so.1What kind of error?
I started apache webserver and got this error.
bash-2.05b$ bin/apachectl start
ld.so.1: httpd: fatal: /usr/sfw/lib/libgcc_s.so.1: wrong ELF class: ELFCLASS32
Also getting same error while executing other command.,
ld.so.1: ls: fatal: /usr/sfw/lib/libgcc_s.so.1: wrong ELF class: ELFCLASS32
I set LD_PRELOAD_32, and problem with ld.so.1: httpd: fatal: /usr/sfw/lib/libgcc_s.so.1: wrong ELF class: ELFCLASS32
Killed gone away but there is no changes in output.
I am still getting core dump.
I set LD_PRELOAD_32, and problem with ld.so.1: httpd: fatal: /usr/sfw/lib/libgcc_s.so.1: wrong ELF class: ELFCLASS32The reason of this error is that your process (httpd) is 64-bit and you are feeding it 32-bit libgcc_s.
gone away but there is no changes in output.
You solved it by stopping feeding it using LD_PRELOAD_32 which has no effect on 64-bit process.
Thus no change in behavior.
Instead you should be using:
(or LD_PRELOAD_64, which should have similar effect).
Hi Fedor, It works for small application which I created to simulate the issue. No core observed.
Now I am trying with original app, will let you know results.
Many Many thanks for yr help.
It works for us. Thank you. Is there any other way to handle it..may be something need to add in link option?
Is there any other way to handle it..may be something need to add in link option?Unfortunately none that I can suggest right away.
I will try asking folks around.
Unfortunatly it works for apache webserver but not for Oracle Http Server. Please help me here.
I have also confirmed with truss output, libgcc_s.so.1 is loaded first. Any other suggestion?