From: "Florian X" Newsgroups: comp.os.msdos.djgpp References: Subject: Re: silly question: SIGSEGV Date: Sun, 21 Jan 2001 11:22:50 +0100 X-Newsreader: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Lines: 74 Message-ID: <3a6ab865$0$25126@SSP1NO25.highway.telekom.at> NNTP-Posting-Host: 212.183.93.153 X-Trace: newsreader01.vienna.highway.telekom.at 980072549 25126 212.183.93.153 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com >Do you mean to say that this bug only shows up if you use DLX, and that >using DLX somehow invalidates the EIP values printed in the crash message? Here is the printed info from symify: Call frame traceback EIPs: 0x000a9b9f _free+247 0x000016c4 _sf_free+24, line 81 of program.c 0x00003d38 _dispose+52, line 1478 of program.c 0xffd94c14 0xffd94c14 <------------- funtktion in the DLX program 0x00003d23 _dispose+31, line 1476 of program.c 0x00002870 _obj_done+92, line 657 of program.c 0x000144c8 _view_done+176, line 129 of program.c 0x00003d23 _dispose+31, line 1476 of program.c 0xffd8c2fa 0xffd8c2fa <------------- funtktion in the DLX program 0x000152cc _view_play_process+176, line 387 of program.c 0x00003b78 _obj_translate_event+44, line 1242 of program.c [DR-DOS] E:\SEALSRC>symify seal.exe >Can you run the program under a debugger? If so, then both GDB and RHIDE >should be able to tell you a lot about each EIP value printed in the >crash message. Perhaps you didn't use the right commands. I used it, but they couldn't show me more infos, because of the DLXs and because some *.c files are included into the main file program.c via fe. #include"object.c". So rhgdb and rhide only opens program.c and cannot show me the line, where the error is :((( BTW: SEAL is a Allegro program, and I can debug once or twice, but when I exit the debuger, I have to use the RESET-Button. (In Dr-DOS (with and without Dr-DOS DPMI), MS-DOS and Win95). >You _must_ find the place in the source code where it crashes. There's >no other way. > >If nothing else helps, you could selectively remove parts of the code in >the approximate area where it crashes, until you arrive at a single line >or maybe a small number of lines whose removal causes the crashes to >appear. Yes, I tried it. I think it tries to remove a memory block which wasn't right allocated via malloc. All free() commands where replaced by a macro like this: #define _free(x) sf_free(x) void sf_free ( void *rec ) { if ( rec ) free(rec); rec = 0; }; > >> Other people have no problem with this program, some has also.....why?? > >Memory-related bugs are usually like that. I hate this bug!! Another problem is, that I haven't developed it, now it is a open source project, and I have to find the bug in a very very big program and have to learn the source. Thanks, florian www.drdos.org www.seal.de.vu -- This mail was written by user of The Arachne Browser - http://arachne.cz/