Recursion crash in STL on linux
in [Unix Programming]
|
Prev: error
Next: Automake Conditional and ARG_VAR Question
From: Sjouke Burry on 27 Apr 2010 20:31 Fred Zwarts wrote: > <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? Last time I had a stack problem, I just wrote a very small assembler routine, to return the value of the stackpointer. That value, as the stack became full , moved to zero. So if your system works likewise, use such a routine to quit at the right moment, while there is still some left.
From: Mickey on 27 Apr 2010 23:22 On Apr 27, 2:27 pm, boltar2...(a)boltar.world wrote: > 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 I am rather sure that it is nothing to do with malloc or stl. It is your code which has corrupted the memory. Use valgrind to find use of uninitialized memory. Try analyzing your code with gdb also. Regards, Jyoti
From: boltar2003 on 28 Apr 2010 05:17 On Wed, 28 Apr 2010 02:31:06 +0200 Sjouke Burry <burrynulnulfour(a)ppllaanneett.nnll> wrote: >> Are you sure that the problem is the stack limit and not another form >> of memory corruption? What does the debugger tell you? >Last time I had a stack problem, I just wrote a very small >assembler routine, to return the value of the stackpointer. >That value, as the stack became full , moved to zero. >So if your system works likewise, use such a routine to >quit at the right moment, while there is still some left. Is there a way of doing that in C rather than assembler? My x86 assembler isn't great but I want the program to be portable anyway. B2003
From: boltar2003 on 28 Apr 2010 05:21 On Tue, 27 Apr 2010 12:16:12 +0200 "Fred Zwarts" <F.Zwarts(a)KVI.nl> wrote: >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=20 >exhaustion of the heap, but by corruption of the internal heap=20 >administration. This could be due to running out of stack space. Thats what I thought , but is there a simple way to check if the stack is about to be used up? I just tried this simple test program and the exact same thing happens: $ cat t.c int main() { func(); } $ cc t.c $ a.out Segmentation fault (core dumped) So clearly running out of stack space causes a SIGSEGV but short of trapping the signal which is usually a waste of time as the program is hopelessly corrupted by that point I'm wondering if theres another way of finding out. B2003
From: boltar2003 on 28 Apr 2010 05:23
On Wed, 28 Apr 2010 09:21:56 +0000 (UTC) boltar2003(a)boltar.world wrote: >$ cat t.c >int main() >{ > func(); >} Sorry , cut and paste went wrong, that obviously should have been: int main() { main(); } B2003 |