core file using gdb - What does this mean?

[david_252]

I have attached the output of analysing a core file with gdb. This Xmotif application generates lots of cores periodically (all applications are launched from PC using Xemulator)We need to understand why it generates so much cores. Can someone help?
--------------------------------------------
Program terminated with signal 10, Bus error.

warning: The shared libraries were not privately mapped; setting a
breakpoint in a shared library will not work until you rerun the program.

#0 0xc0183370 in mallinfo () from /usr/lib/libc.2

(gdb) bt
#0 0xc0183370 in mallinfo () from /usr/lib/libc.2
#1 0xc0185fc8 in free () from /usr/lib/libc.2
#2 0xc4153998 in XtFree () from /usr/lib/X11R6/libXt.3
#3 0xc4313454 in _XmTextInvalidate () from /usr/lib/Motif2.1/libXm.4
#4 0xc4332a2c in Replace () from /usr/lib/Motif2.1/libXm.4
#5 0xc43325f0 in _XmTextModifyVerify () from /usr/lib/Motif2.1/libXm.4
#6 0xc4314af4 in SetValues () from /usr/lib/Motif2.1/libXm.4
#7 0xc4314620 in Resize () from /usr/lib/Motif2.1/libXm.4
#8 0xc418014c in XtSetValues () from /usr/lib/X11R6/libXt.3
#9 0xc4194b4c in XtVaSetValues () from /usr/lib/X11R6/libXt.3
#10 0xcb17c in baseAS::clearWindow (this=0x40018c10) at base_cdlg.C:5188
#11 0xc508c in baseAS::endAccount (this=0x40018c10) at base_cdlg.C:3053
#12 0xc9018 in baseAS::profileEventHandler (
No.Identifier=0x680f0ffc "\001\001C\240CP", objP=0x40018c10,
ev=0x680f0cb0, No.Identifier=0x680f0ffc "\001\001C\240CP")
at base_cdlg.C:4576
#13 0xc4164dfc in CallEventHandlers () from /usr/lib/X11R6/libXt.3
#14 0xc4164ff0 in XtDispatchEventToWidget () from /usr/lib/X11R6/libXt.3
#15 0xc4166038 in _XtDefaultDispatcher () from /usr/lib/X11R6/libXt.3
#16 0xc4166310 in XtDispatchEvent () from /usr/lib/X11R6/libXt.3
#17 0xc41669dc in XtAppMainLoop () from /usr/lib/X11R6/libXt.3
#18 0x4179c in main (argc=1, argv=0x680f093c) at uxb_main.C:132
-------------------------------------------

Thanks
David.

[Steven E. Protter]

It probably means your SHLIB_PATH variable isn't set right.

Is it a consistent error or intermittant.


SEP

[A. Clay Stephenson]

The problem seems to be in free() - I suspect that the mallinfo() is an artifact. Note that free() is fall up the call chain. The classic reasons for this sort of error include 1) free()'ing blocks of memory that were never dynamically allocated in the first place 2) freeing an invalid address 3) freeing the same block of memory more than once.

[david_252]

Hi:

The SHLIB_PATH path is not a problem.

Thanks

David.

[Adam J Markiewicz]

Try to use a tool that monitors malloc() and free() calls. It can do three things for you:
1. Scratch newly allocated memory to check if you force initialisation of everything you use
2. Scratch memory before free to check if you do not try to use it afterwards.
3. Check if you free memory that was properly allocated.

If something is wrong you should have crash earlier, then before, however current position should be closer to buggy code.

Good luck
Adam