On Mar 21, 2006, at 2:06 PM, Wyles Eric - ewyles wrote:
Now for the actual problem. Once in a while, our application
crashes with a segmentation fault. The stack trace looks like this:
Received signal 11 (Segmentation fault) from process [4]
Stack Trace:
0 : <application_name>
(_ZN14clsApplication18FatalSignalHandlerEiP7siginfoPv+0x27e)
[0x80fc050]
1 : /lib/tls/libpthread.so.0 [0xf93e50]
2 : /usr/local/hive/i386/ags/lib/liblog4cxx.so
(_ZN7log4cxx9Hierarchy9getLoggerERKSsRKNS_7helpers10ObjectPtrTINS_3spi
13LoggerFactoryEEE+0x251) [0x608a09]
3 : /usr/local/hive/i386/ags/lib/liblog4cxx.so
(_ZN7log4cxx9Hierarchy9getLoggerERKSs+0x39) [0x6087ab]
4 : /usr/local/hive/i386/ags/lib/liblog4cxx.so
(_ZN7log4cxx10LogManager9getLoggerERKSs+0x3c) [0x57528a]
5 : /usr/local/hive/i386/ags/lib/liblog4cxx.so
(_ZN7log4cxx6Logger9getLoggerEPKc+0x53) [0x6063b9]
6-14 : <various classes specific to our application>
15 : /lib/tls/libpthread.so.0 [0xf8ddec]
16 : /lib/tls/libc.so.6(__clone+0x5a) [0xb9da2a]
Is the application-specific part of the calling stack consistent? Is
the method that calls getLogger() (level 6) consistent? If so, if
you comment out the method-local logger (which should result in the
class logger being used), do you still observe the segmentation
faults? If so, is there anything peculiar about that method.
