Hello all, I've found a bug in gdb that I'm pretty sure is a memory leak (either that or an infinite regression). Here's the general description of how I produced it:
I have a fairly small program that uses Xerces-C. When run normally (or under Linux's gdb) there is no problem at all. When run under Cygwin's gdb, with just "run" and no fancy breakpoints, no problem either. However, when I "next" through the code (at least in -w mode - haven't gotten around to trying in textmode yet) the program eats 100% CPU and (eventually) 100% memory when I "next" over a Xerces-C setErrorHandler() on a DOMImplementationLS parser. Eventually, it eats all of my memory, the system complains of a lack of virtual memory and the program dies. Until that time, my system is pretty useless. When it's done strace-ing, I'll attach the file (I'll go get a cup of coffee first - I have a lot of memory to waste). In the mean time, I've noticed that gdb does not have any debug information, so I can't do much in the way of debugging this problem. What I got from tailing the strace looks like a memory leak to me, but as I have no idea how gdb works internally, I can't make much of it... I'll provide a small test case if I can get one to fail with the same error. As Cygwin is only a debug platform for me, and the code I work on is proprietary, I can't send you the code of the failing program itself :( Other interesting facts: while doing "next" over the instruction makes the program misbehave, putting a breakpoint just behind it and "continue"-ing doesn't! (Kinda makes me wonder how "next" is implemented...) Using the Windows taskmanager shows it really is gdb eating up all my memory. The strace output file has eaten up all of my disk space before gdb got around to eating up all of my memory, so I couldn't quite let it go to the end the first time around. The second time, my system no longer responded so I couldn't get any strace at all, do the third time, I decided to stop it after 10 minutes killing gdb from the task manager. An earlier run produced a stackdump, which I jave attached as well. Hope it helps. If you need more info, just ask. Ronald Landheer-Cieslak (rlc)
strace.out.gz
Description: strace output
1523564658 [sig] gdb 390 handle_exceptions: Exception: STATUS_STACK_OVERFLOW Exception: STATUS_STACK_OVERFLOW at eip=610BCA03 eax=00001038 ebx=00000000 ecx=00CBBBB8 edx=610C4684 esi=00000000 edi=00010007 ebp=00CBFBB8 esp=00CBFBB0 program=C:\cygwin\bin\gdb.exe cs=001B ds=0023 es=0023 fs=0038 gs=0000 ss=0023 Stack trace: Frame Function Args 00CBFBB8 610BCA03 (61011D00, 00227568, 00000001, 00000000) 00CBFBD8 61011DE8 (00227568, 00000001, 00000001, 61013F2D) 00CBFF08 610141B3 (00000006, 00000001, 61074DED, 61074EE1) 00CBFF88 610754F1 (610C3628, 806B29E0, F16F2E20, 8096DBA4) 00CBFFB8 610053E8 (610C3628, 77DC0000, 0022FD8C, 610C3628) 00CBFFEC 77F04EDE (61005340, 610C3628, 00000000, 000000B0) End of stack trace
-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
