Core Dump not getting created

[madhi]

Hi,

In my application [Runs with SLES10 on Ia64], I use dlopen() call to open .so libraries which crashes the system and reboots automatically.
In make file I am compiling with –g options and trying to create core dump using “ulimit -c unlimited” option but in vain,
This crash happens only with SLES 10 not with SLES 9 or SLES 11 OS.
No error message is logged under var/log/messages when crash occurs

Please let me if I miss anything. Thanks in advance

-Madhi

[Rubberman]

This is not enough information to go on. Can you please provide an example of the code that causes the core dump. Also, ulimit has nothing (as far as I know) with causing the system to create a core file when it crashes. What does it do when you run it inside gdb? Have you built it with -g and avoided stripping the executables, objects, or libraries?

[madhi]

Hi Rubberman,

Thanks for the reply,

I compiled with -g option and taken care of stripping

while i run gdb and step into line 4 of the code below, the system crashes and restarts automatically, I understand this issue as kernal panic rather application crash if so any method to fix

code:
1. DLIBREF OpenDynamicLib( char* LibName )
2. {
3. DLIBREF result;
4. result = dlopen( LibName, RTLD_LAZY );
5. if ( result == NULL )
6. {
7. printf( dlerror() );
8. printf( "\ncould not open %s.\n", LibName );
9. }
10. return result;
11. }

[Rubberman]

Hi Rubberman,

Thanks for the reply,

I compiled with -g option and taken care of stripping

while i run gdb and step into line 4 of the code below, the system crashes and restarts automatically, I understand this issue as kernal panic rather application crash if so any method to fix

code:
1. DLIBREF OpenDynamicLib( char* LibName )
2. {
3. DLIBREF result;
4. result = dlopen( LibName, RTLD_LAZY );
5. if ( result == NULL )
6. {
7. printf( dlerror() );
8. printf( "\ncould not open %s.\n", LibName );
9. }
10. return result;
11. }

Ah! A kernel panic is a very different beast! Your system should produce a kernel dump in such a case. Have you looked at that? It is unusual for loading a shared library to cause a kernel panic unless it has kernel code in it, or if it is for the wrong platform (64-bit in a 32-bit environment, or wrong processor family), or if it contains embedded assembly language (machine code) that fubars the system. Do you have access to the library code, or is it proprietary such as the Oracle OCI libraries?