Weird Seg Fault

Discussion:

Weird Seg Fault

(too old to reply)

David Steiner

2009-04-02 02:42:29 UTC

Hi,

So I'm baffled... I am getting a seg fault at some point AFTER my program
returns... Here is my gdb output:

Program received signal SIGSEGV, Segmentation fault.
0xff0cded8 in __do_global_dtors_aux () from
/software/gcc-3.4.2_runtime/lib/libstdc++.so.6
(gdb) bt
#0 0xff0cded8 in __do_global_dtors_aux () from
/software/gcc-3.4.2_runtime/lib/libstdc++.so.6
#1 0xff0cdeac in _fini () from
/software/gcc-3.4.2_runtime/lib/libstdc++.so.6
#2 0xff1c0c70 in ?? ()
Previous frame identical to this frame (corrupt stack?)

Now this actually happens after my main method returns, or on my main
method's return call, becuase I have a cout statement right before "return
0", which prints without a problem. Is it some kind of cleanup issue???

Any help is appreciated! Thanks,
Dave

Martin Karsten

2009-04-02 02:52:47 UTC

Permalink

Without knowing more details, I can only give you general advice about this:

1) Static objects are allocated before main is called and destroyed after main
returns. The reference '__do_global_dtors_aux' points in this direction. Do you
use any static objects that could cause this?

2) Another guess is that some (any) kind of memory corruption happens, probably
originating from a stray pointer. This memory corruption then triggers a problem
(later) during the destructor of a seemingly unrelated global object that exists
in the runtime environment (e.g. from a library). In this case, you need a
memory debugger to track down the problem. Or very thorough code inspection...

3) Finally, if there are automatic objects that are created during main, their
destructor would also be executed at the end of the routine, i.e. after any
final printout. However, the stack backtrace seems rather to point to 2)

Post by David Steiner
Hi,
So I'm baffled... I am getting a seg fault at some point AFTER my
Program received signal SIGSEGV, Segmentation fault.
0xff0cded8 in __do_global_dtors_aux () from
/software/gcc-3.4.2_runtime/lib/libstdc++.so.6
(gdb) bt
#0 0xff0cded8 in __do_global_dtors_aux () from
/software/gcc-3.4.2_runtime/lib/libstdc++.so.6
#1 0xff0cdeac in _fini () from
/software/gcc-3.4.2_runtime/lib/libstdc++.so.6
#2 0xff1c0c70 in ?? ()
Previous frame identical to this frame (corrupt stack?)
Now this actually happens after my main method returns, or on my main
method's return call, becuase I have a cout statement right before
"return 0", which prints without a problem. Is it some kind of cleanup
issue???
Any help is appreciated! Thanks,
Dave

David Steiner

2009-04-02 03:18:15 UTC

Permalink

So I think i've narrowed it down...

When I'm reading in from my infile, i'm using the istream::read method,
and sending it a pointer to a char*. If this reads past the EOF marker,
for some reason it is padding my char* buffer with a whole bunch of
giberish...

Now, if I change the char* to a char[512], it no longer seg faults, but
for some reason then nothing gets written to my outfile...

Not sure if this helps, but just a further thought...

Post by Martin Karsten
1) Static objects are allocated before main is called and destroyed after main
returns. The reference '__do_global_dtors_aux' points in this direction. Do you
use any static objects that could cause this?
2) Another guess is that some (any) kind of memory corruption happens, probably
originating from a stray pointer. This memory corruption then triggers a problem
(later) during the destructor of a seemingly unrelated global object that exists
in the runtime environment (e.g. from a library). In this case, you need a
memory debugger to track down the problem. Or very thorough code inspection...
3) Finally, if there are automatic objects that are created during main, their
destructor would also be executed at the end of the routine, i.e. after any
final printout. However, the stack backtrace seems rather to point to 2)

Martin Karsten

2009-04-02 13:11:43 UTC

Permalink

Just curious from the way you have formulated this: When you give the char* to
the istream::read function, does it point to allocated memory? Otherwise random
memory (wherever the pointer happens to point to) will be overwritten by
istream::read.

Post by David Steiner
So I think i've narrowed it down...
When I'm reading in from my infile, i'm using the istream::read method,
and sending it a pointer to a char*. If this reads past the EOF marker,
for some reason it is padding my char* buffer with a whole bunch of
giberish...
Now, if I change the char* to a char[512], it no longer seg faults, but
for some reason then nothing gets written to my outfile...
Not sure if this helps, but just a further thought...

Post by Martin Karsten
1) Static objects are allocated before main is called and destroyed after main
returns. The reference '__do_global_dtors_aux' points in this
direction. Do you
use any static objects that could cause this?
2) Another guess is that some (any) kind of memory corruption happens, probably
originating from a stray pointer. This memory corruption then triggers a problem
(later) during the destructor of a seemingly unrelated global object that exists
in the runtime environment (e.g. from a library). In this case, you need a
memory debugger to track down the problem. Or very thorough code inspection...
3) Finally, if there are automatic objects that are created during main, their
destructor would also be executed at the end of the routine, i.e. after any
final printout. However, the stack backtrace seems rather to point to 2)