Prev: error
Next: Automake Conditional and ARG_VAR Question
From: boltar2003 on 27 Apr 2010 05:27
Hi

I don't know if this is a gcc C++ implementation issue (I suspect it is) or a
linux issue so I'm hedging my bets by posting to 2 newsgroups.

I have a C++ program for linux that does a LOT of recursion due to searching
etc which I won't bore you with but I am getting consistent crashes in the
STL. This appears to be due to running out of stack or heap space but all
that happens is the container crashes , there is no exception thrown and no way
of knowing when its going to happen. Sure I can limit recursion depth but
it would be nice to know when the stack limit is about to be hit.

So does anyone know a way in linux of checking the amount of stack space or
heap space left for a process (hopefully not something kludgy like attempting
to just malloc a large amount of memory to see what happens) or

is there a way to get around this apparent bug in the STL and make it chuck an
exception if this sort of thing happens?

There are 2 sorts of crashes I'm getting , one is a malloc() failure in new
(doesn't it check for NULL return from malloc??):

Program received signal SIGSEGV, Segmentation fault.
0xb76317e0 in malloc_consolidate () from /lib/libc.so.6
(gdb) bt
#0 0xb76317e0 in malloc_consolidate () from /lib/libc.so.6
#1 0xb76336e5 in _int_malloc () from /lib/libc.so.6
#2 0xb7635545 in malloc () from /lib/libc.so.6
#3 0xb7809d07 in operator new () from /usr/lib/libstdc++.so.6
#4 0x08058e68 in __gnu_cxx::new_allocator<cl_result*>::allocate (
this=0xbf435360, __n=128)
at /usr/lib/gcc/i486-slackware-linux/4.3.3/../../../../include/c++/4.3.3/
ext/new_allocator.h:92
#5 0x08058e92 in std::_Deque_base<cl_result*, std::allocator<cl_result*> >::
_M_allocate_node (this=0xbf435360)


and the other is something rather more obscure though probably related:

Program received signal SIGSEGV, Segmentation fault.
0x08057770 in std::__copy_move<false, false, std::random_access_iterator_tag>
::__copy_m<std::_Deque_iterator<cl_result*, cl_result* const&, cl_result*
const*>, std::_Deque_iterator<cl_result*, cl_result*&, cl_result**> >
(__first=
{_M_cur = 0x9c88b68, _M_first = 0x9c88b68, _M_last = 0x9c88d68, _M_node =
0x9c88464}, __last=
{_M_cur = 0x9c88b68, _M_first = 0x9c88b68, _M_last = 0x9c88d68, _M_node =
0x9c88464}, __result=
{_M_cur = 0xbf5dd088, _M_first = 0x0, _M_last = 0x0, _M_node =
0xbf5dd3c0})
at /usr/lib/gcc/i486-slackware-linux/4.3.3/../../../../include/c++/4.3.3/
bits/stl_algobase.h:340
340 for(_Distance __n = __last - __first; __n > 0; --__n)


Though the actual crash point varies.

Thanks for any help.

B2003


From: Fred Zwarts on 27 Apr 2010 06:16
<boltar2003(a)boltar.world> wrote in message
news:hr6am8$op0$1(a)speranza.aioe.org
> Hi
>
> I don't know if this is a gcc C++ implementation issue (I suspect it
> is) or a linux issue so I'm hedging my bets by posting to 2
> newsgroups.
>
> I have a C++ program for linux that does a LOT of recursion due to
> searching etc which I won't bore you with but I am getting consistent
> crashes in the STL. This appears to be due to running out of stack or
> heap space but all
> that happens is the container crashes , there is no exception thrown
> and no way of knowing when its going to happen. Sure I can limit
> recursion depth but
> it would be nice to know when the stack limit is about to be hit.
>
> So does anyone know a way in linux of checking the amount of stack
> space or heap space left for a process (hopefully not something
> kludgy like attempting to just malloc a large amount of memory to see
> what happens) or
>
> is there a way to get around this apparent bug in the STL and make it
> chuck an exception if this sort of thing happens?
>
> There are 2 sorts of crashes I'm getting , one is a malloc() failure
> in new (doesn't it check for NULL return from malloc??):

Yes it does, but as you see in the following, malloc does not return.
There is a SIGSEGV crash in malloc. This is usually not caused by
exhaustion of the heap, but by corruption of the internal heap
administration. This could be due to running out of stack space.

>
> Program received signal SIGSEGV, Segmentation fault.
> 0xb76317e0 in malloc_consolidate () from /lib/libc.so.6
> (gdb) bt
> #0 0xb76317e0 in malloc_consolidate () from /lib/libc.so.6
> #1 0xb76336e5 in _int_malloc () from /lib/libc.so.6
> #2 0xb7635545 in malloc () from /lib/libc.so.6
> #3 0xb7809d07 in operator new () from /usr/lib/libstdc++.so.6
> #4 0x08058e68 in __gnu_cxx::new_allocator<cl_result*>::allocate (
> this=0xbf435360, __n=128)
> at
> /usr/lib/gcc/i486-slackware-linux/4.3.3/../../../../include/c++/4.3.3/
> ext/new_allocator.h:92 #5 0x08058e92 in std::_Deque_base<cl_result*,
> std::allocator<cl_result*> >:: _M_allocate_node (this=0xbf435360)
>
>
> and the other is something rather more obscure though probably
> related:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x08057770 in std::__copy_move<false, false,
> std::random_access_iterator_tag>
>> :__copy_m<std::_Deque_iterator<cl_result*, cl_result* const&,
>> cl_result*
> const*>, std::_Deque_iterator<cl_result*, cl_result*&, cl_result**> >
> (__first=
> {_M_cur = 0x9c88b68, _M_first = 0x9c88b68, _M_last = 0x9c88d68,
> _M_node = 0x9c88464}, __last=
> {_M_cur = 0x9c88b68, _M_first = 0x9c88b68, _M_last = 0x9c88d68,
> _M_node = 0x9c88464}, __result=
> {_M_cur = 0xbf5dd088, _M_first = 0x0, _M_last = 0x0, _M_node =
> 0xbf5dd3c0})
> at
> /usr/lib/gcc/i486-slackware-linux/4.3.3/../../../../include/c++/4.3.3/
> bits/stl_algobase.h:340 340 for(_Distance __n = __last
> - __first; __n > 0; --__n)
>
>
> Though the actual crash point varies.
>
> Thanks for any help.

Are you sure that the problem is the stack limit and not another form
of memory corruption? What does the debugger tell you?
From: Victor Bazarov on 27 Apr 2010 08:04
boltar2003(a)boltar.world wrote:
> I don't know if this is a gcc C++ implementation issue (I suspect it is) or a
> linux issue so I'm hedging my bets by posting to 2 newsgroups.
>
> [..]

In addition to Fred's response, here is a penny (only 1/2 as useful as
my usual $0.02): 'comp.lang.c++' is *NOT* a newsgroup for posts about a
"gcc C++ implementation issue". You have 'gnu.gcc.*' hierarchy for that.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
From: Daniel T. on 27 Apr 2010 08:35
boltar2003(a)boltar.world wrote:

> I don't know if this is a gcc C++ implementation issue (I suspect it
> is) or a linux issue so I'm hedging my bets by posting to 2
> newsgroups.
>
> I have a C++ program for linux that does a LOT of recursion due to
> searching etc which I won't bore you with but I am getting consistent
> crashes in the STL. This appears to be due to running out of stack or
> heap space but all that happens is the container crashes , there is no
> exception thrown and no way of knowing when its going to happen. Sure
> I can limit recursion depth but it would be nice to know when the
> stack limit is about to be hit.
>
> So does anyone know a way in linux of checking the amount of stack
> space or heap space left for a process (hopefully not something kludgy
> like attempting to just malloc a large amount of memory to see what
> happens) or
>
> is there a way to get around this apparent bug in the STL and make it
> chuck an exception if this sort of thing happens?

This is not a bug in the STL.

Guarding against memory corruption requires a lot of overhead and even
then it isn't guaranteed to be successful. C++ errs on the side of
running lean so if you want such guards, you have to implement them
yourself (or find a tool that does it for you.)

What I would do in your shoes is (1) try to isolate the recursive
algorithm and prove that it works with test cases. (2) use the test
cases to convert the recursive algorithm to an iterative algorithm. (3)
put the iterative algorithm into the main program and see if the bug
still happens.

If the bug is gone, then you can be reasonably sure that it was due to
overflowing the stack and continue with the project. If the bug is still
there (it will have moved, but it will still be a SIGSEGV,) then you can
be reasonably sure that there is undefined behavior somewhere in your
program (most likely dereferencing an uninitialized pointer, or a
pointer that is pointing to a deleted object.)

Good luck.
From: Ralf Fassel on 27 Apr 2010 08:50
* boltar2003(a)boltar.world
| So does anyone know a way in linux of checking the amount of stack space or
| heap space left for a process (hopefully not something kludgy like attempting
| to just malloc a large amount of memory to see what happens) or

On Linux, use valgrind http://valgrind.org/ to see where your program
corrupts the memory as it happens, not afterwards when the SEGV occurs.

R'
 |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: error
Next: Automake Conditional and ARG_VAR Question