Menu
▾
▴
[Mingw-notify] [ mingw-Bugs-709036 ] gdb access violation when debugging
|
From: SourceForge.net <no...@so...> - 2007-05-16 15:54:23
|
Bugs item #709036, was opened at 2003-03-24 16:55 Message generated for change (Comment added) made by wsm2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=709036&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: gdb Group: Known bugs Status: Open Resolution: None Priority: 5 Private: No Submitted By: Vladimir Michl (michlv) Assigned to: Nobody/Anonymous (nobody) Summary: gdb access violation when debugging Initial Comment: Hello dovelopers, I compile some C++ program which have too much classes (such of this have all members static) with mingw 2.0.0 (gcc 3.2) mingw-runtime 2.4, w32api 2.2. Flags when compiling is -mms-bitfields -mwin32 -mno-cygwin -Wall $(VERSION) -g -mconsole linked libraries are -lkernel32 -ladvapi32 -lws2_32 -lstdc++ When I try trace program in main() (with next command) on second line gdb cause access violation. Command 'dissasemble main' cause access vialation too. I think that gdb has corrupted symbol table, because access violation is caused when show (in disassemble) call to ___chkstk function (show to objdump -d cipsrvr.exe) I attach compiled binary which cause gdb access violation. I try gdb 5.1.1 and gdb 5.2.1 with the same result. ---------------------------------------------------------------------- Comment By: Wayne M (wsm2) Date: 2007-05-16 10:54 Message: Logged In: YES user_id=1313445 Originator: NO reporter states "I do not use any of that any more. Possibly I do not even have the original sources" ---------------------------------------------------------------------- Comment By: Vladimir Michl (michlv) Date: 2003-04-02 02:41 Message: Logged In: YES user_id=213474 gcc 3.2.2 my program compiled with gcc 3.2.2. gdb 5.2.1 compiled with gcc 3.2.2. configured with: ./configure under msys-1.0.8. after run gdb on gdb with my compiled program and type: in debugged gdb: (gdb) disassemble main Dump of assembler code for function main: 0x401636 <main>: push %ebp 0x401637 <main+1>: mov %esp,%ebp 0x401639 <main+3>: push %edi 0x40163a <main+4>: push %esi 0x40163b <main+5>: push %ebx 0x40163c <main+6>: sub $0x9c,%esp 0x401642 <main+12>: and $0xfffffff0,%esp 0x401645 <main+15>: mov $0x0,%eax 0x40164a <main+20>: mov %eax,0xffffff80(%ebp) 0x40164d <main+23>: mov 0xffffff80(%ebp),%eax 0x401650 <main+26>: call 0x426650 During symbol reading, inner block (0x40dc92-0x40df2e) not inside outer block (0 x0-0x21). In top-gdb: Program received signal SIGSEGV, Segmentation fault. finish_block (symbol=0x0, listhead=0x5aed90, old_blocks=0xabababab, start=0, end=33, objfile=0x10b3d88) at buildsym.c:388 388 if (BLOCK_SUPERBLOCK (pblock->block) == NULL) (top-gdb) bt #0 finish_block (symbol=0x0, listhead=0x5aed90, old_blocks=0xabababab, start=0, end=33, objfile=0x10b3d88) at buildsym.c:388 #1 0x004b0525 in process_one_symbol (type=36, desc=0, valu=33, name=0x1190028 "", section_offsets=0x10b8f70, objfile=0x10b3d88) at dbxread.c:2758 #2 0x004afc43 in read_ofile_symtab (pst=0x13b79c0) at dbxread.c:2602 #3 0x004af77f in dbx_psymtab_to_symtab_1 (pst=0x13b79c0) at dbxread.c:2430 #4 0x004af715 in dbx_psymtab_to_symtab_1 (pst=0x13b9278) at dbxread.c:2416 #5 0x004af715 in dbx_psymtab_to_symtab_1 (pst=0x138b960) at dbxread.c:2416 #6 0x004af893 in dbx_psymtab_to_symtab (pst=0x138b960) at dbxread.c:2471 #7 0x00405b13 in psymtab_to_symtab (pst=0x138b960) at symfile.c:374 #8 0x004678e8 in blockvector_for_pc_sect (pc=4351568, section=0x0, pindex=0x22f7a4, symtab=0x0) at blockframe.c:585 #9 0x00467948 in block_for_pc_sect (pc=4351568, section=0x0) at blockframe.c:644 #10 0x004679a3 in find_pc_sect_function (pc=4351568, section=0x0) at blockframe.c:665 #11 0x0044d972 in build_address_symbolic (addr=4351568, do_demangle=0, name=0x22f868, offset=0x22f858, filename=0x22f864, line=0x22f85c, unmapped=0x22f860) at printcmd.c:647 #12 0x0044d84e in print_address_symbolic (addr=4351568, stream=0x3d3d70, do_demangle=0, leadin=0x44dc46 " ") at printcmd.c:559 #13 0x0044dc77 in print_address (addr=4351568, stream=0x3d3d70) ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2003-03-28 20:38 Message: Logged In: YES user_id=11494 Sorry, I wasn't clear. The problem may be that gdb was compiled with 3.2.0 or 3.1 so has stack corruption fault. Danny ---------------------------------------------------------------------- Comment By: Vladimir Michl (michlv) Date: 2003-03-28 17:25 Message: Logged In: YES user_id=213474 Now is in gcc 3.2.2-20030208 downloadable from sourceforge? I try compile binary without -O2 only with -g. The result is the same -> access violation. I try gcc 3.2 and gcc 3.2.2-20030208. If binary is compiled without -g and without -O2 or with -O2, main may be disassembled without crash. (gcc 3.2.2). Because sourceforge.net accept attached files only to 256KB size, compiled zipped binary which crash gdb may be downloaded from http://hlubocky.del.cz/~michlv/mingw/CIPSRVR.ZIP. ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2003-03-24 17:26 Message: Logged In: YES user_id=11494 There is an _alloca/_chkstck bug in gcc3.2 for cygwin and mingw that is exposed at -O2 and higher when large arrays or structs (> 4kb) are allocated on the stack This _may_ be the problem. That bug is fixed now. Danny ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=709036&group_id=2435 |
