- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi All,
We have a webplugin which is complied/linked using GCC3.3.2 on RHEL3.0.
We are loading this webplugin on Oracle HTTP Server 2 (OHS-2) , which is compiled and linked using icc compiler.
We execute stress test client which sends multiple http request to the OHS2 server containing our plugin.
During run of this client we are observing core dumps on OHS2 webserver.
After analyzing the core dumps using gdb , we came to know that "this" pointer is getting set to NULL in the desctructor of the object, which leads to crash.
Our pluging require old threading mode (2.4.19), while the OHS2 server on Linux uses the latest theread model.For running our plugin we explicitly set LD_ASSUME_KERNEL=2.4.19.
Is there any known issue while running GCC3.3.2 compiled librarries on OHS2( compiled using ICC).
Any kind of help will be appreciated.
Thanks and Regards
Raj Mishra
We have a webplugin which is complied/linked using GCC3.3.2 on RHEL3.0.
We are loading this webplugin on Oracle HTTP Server 2 (OHS-2) , which is compiled and linked using icc compiler.
We execute stress test client which sends multiple http request to the OHS2 server containing our plugin.
During run of this client we are observing core dumps on OHS2 webserver.
After analyzing the core dumps using gdb , we came to know that "this" pointer is getting set to NULL in the desctructor of the object, which leads to crash.
Our pluging require old threading mode (2.4.19), while the OHS2 server on Linux uses the latest theread model.For running our plugin we explicitly set LD_ASSUME_KERNEL=2.4.19.
Is there any known issue while running GCC3.3.2 compiled librarries on OHS2( compiled using ICC).
Any kind of help will be appreciated.
Thanks and Regards
Raj Mishra
Link Copied
1 Reply
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you are running an optimized build, the this pointer you see in the debugger may not necesserely be what it actually is. I can't speak for GCC on Linux, but on Windows this is passed into methods in the ecx/rcx register and if you are analyzing variables in a debugger, this may appear to be anything that the current value of ecx/rcx is.
Try turning off optimizations and see if this fixes the problem. If not, at least you will have a usable call stack next time.
Try turning off optimizations and see if this fixes the problem. If not, at least you will have a usable call stack next time.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page