we have an issue like this, app1 and app2 both use shared_lib.so.

overnight the apps crashed and generated a code dump.

the core dump is from app2, when we load it to gdb, the stack shows functions can only be called from app1.
so we are totally lost, have you seen such things before ?

Thanks very much !

Are you absolutely certain those functions don't exist in the shared library?
I think you can use nm to list the symbols of the shared library

> the core dump is from app2, when we load it to gdb, the stack shows functions can only be called from app1.

Guess it means: functions that are not supposed to be called from app2...

Many bugs in a program can corrupt the stack so that gdb displays an incorrect back trace. Sometimes gdb just displays an incorrect backtrace without any stack corruption.
So you need to consider both the possibility that gdb is showing an incorrect backtrace and the possibility that functions are called by app2 that you did not expect to be called by app2.
Take a closer look at what gdb is showing you and figure out what makes more sense.
The raw contents of registers and memory (including the stack) are correctly shown by gdb. So you can see what was really there at the moment of the crash. Higher interpretations of that data (such as a backtrace or the contents of named local variables) shown by gdb must be looked at with some amount of distrust.

yes this is what i mean

actually the back trace shows at the line like this,

func()
{
............
{
static DWORD var = 0;
var++;
}
}

wondering if static variable in shared lib could have troubles.

What kind of "troubles"?

I'm nearly sure static variables in .so libraries are NOT shared across executable, even when the rest of the .so is shared.

In C++ (not sure about C) function static variables can have run time execution, even when the function containing them does not get executed. But that doesn't seem like it would be the case for the example you gave.

You should look at the entire call stack to see if it makes sense.

What does command 'backtrace' say?

warning: core file may not match specified executable file.
[New LWP 3387]
[New LWP 3307]
[New LWP 3818]
[New LWP 3247]
[New LWP 3313]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabi/libthread_db.so.1".
Core was generated by `'.
Program terminated with signal 11, Segmentation fault.
#0 0x403872e8 in ?? () from /opt/ultra/lib/libsub_system.so.1
(gdb) where
#0 0x403872e8 in ?? () from /opt/ultra/lib/libsub_system.so.1
#1 0x403761c8 in TimerManager::ProcessMessage(void*) ()
from /opt/ultra/lib/libsub_system.so.1
#2 0x000a6928 in ?? ()
#3 0x000a6928 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

don't understand why no complete call stack.

http://stackoverflow.com/questions/2...n-program-exit

not exact the same, but ...

That's a clue. What command are you passing to gdb?

just as normal,
gdb image_name core_filename