regarding core dump

[news.fe.internet.bosch.com]

Hi,

I have c++ application which dumps core only static mode and not in
debug mode , I used gdb debugger to know which function is reason for
core dump , is there other ways to find it out.

Mohan

[Victor Bazarov]

news.fe.interne t.bosch.com wrote:

I have c++ application which dumps core only static mode and not in
debug mode , I used gdb debugger to know which function is reason for
core dump , is there other ways to find it out.

If debugging doesn't help (which is possible), I use the tried-and-true
bisection method: introduce output statements clearly before (a) and after
(b) the place where it might be failing, then place yet another point in
the middle (c) and see which ones you actually get. If it's only (a),
move the (c) up, if it's both (a) and (c), move (c) down. Yes, I know,
seems like neither (b) nor (a) are actually necessary, but I say, put them
in anyway, perhaps when you feel like it you might want to tighten the
range by moving (a) down and/or (b) up.

Yes, having output in your program does change its behaviour and will, no
doubt, affect the result of the program execution to the point when the
failure may actually never show up. Well, you'll have to deal with that
then, I guess.

Victor
--
Please remove capital As from my address when replying by mail

[Daniel T.]

In article <ds**********@n s2.fe.internet. bosch.com>,
"news.fe.intern et.bosch.com" <mo**********@i n.bosch.com> wrote:

Hi,

I have c++ application which dumps core only static mode and not in
debug mode , I used gdb debugger to know which function is reason for
core dump , is there other ways to find it out.

Chances are, you are overwriting memory somewhere in your code. Knowing
in which function the core dump occurs will in no way let you know what
code has the error. You need to go through your code (by hand) and find
the spot where you went past the bounds of an array, or assigned to an
invalid pointer.

Sorry for the bad news...

--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.

[Default User]

news.fe.interne t.bosch.com wrote:

Hi,

I have c++ application which dumps core only static mode and not in
debug mode , I used gdb debugger to know which function is reason for
core dump , is there other ways to find it out.

A common cause for debug/release disparity has to do with
initialization of automatic variables. Many implementations will
default initialize to 0 (or equivalent) in debug but leave the vars
uninitialized in release mode. A good first step is to go through and
make sure all variables are initialized one way or another.

Otherwise, I'd proceed as Victor suggested.

Brian

--
Please quote enough of the previous message for context. To do so from
Google, click "show options" and use the Reply shown in the expanded
header.

[Stephan Brönnimann]

news.fe.interne t.bosch.com wrote:

Hi,

I have c++ application which dumps core only static mode and not in
debug mode , I used gdb debugger to know which function is reason for
core dump , is there other ways to find it out.

Mohan

After having the other suggestions that have been posted I got the
following idea:
print the addresses of all variables in the "faulty" function and
compare against the values when debugging: check for unreasonable
differences.

Regards, Stephan