Date: Tue, 4 Aug 1998 05:24:21 +0000 ( ) From: "Gurunandan R. Bhat" To: Martin Str|mberg Cc: djgpp AT delorie DOT com Subject: Re: fsdb crashes post emacs In-Reply-To: <6pvlv3$hep$1@news.luth.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On 1 Aug 1998, Martin Str|mberg wrote: > Hmm. I wonder what makefile.cws is? Why not use makefile? I *think* makefile.cws builds fsdb only. The makefile in the directory src/debug/fsdb looks like it does other things too. > : xorl %%al, %%al > > How did you correct it? xorb or %%eax? And where (line number)? Actually there is only one occurence of this staement in fullscr.c and a simple search will get you a line number. Unfortunately, the machine where I work is very far from the machine where I mail. I changed it thus: xorb %%al, %%al > : Call frame traceback EIPs: > : 0x00013748 _malloc+192 > : 0x00013229 _xmalloc+21 > : 0x000080a5 _initdisplay+133, line 2147 of fullscr.c > : 0x00008c90 _initialize+364, line 2431 of fullscr.c > : 0x0000aec8 _debugger+52, line 3456 of fullscr.c > : 0x000020af _main+503, line 139 of ed.c > : 0x00012c5a ___crt1_startup+454 > : ----------------------------------------------------------- > Now when you have debug info in fsdb, you could try to run it in > gdb... Or add some "fprintf(stderr, ...)"s just before line 2147 of > fullscr.c to see what it passes to xmalloc. I have now built fsdb by linking in malloc by hand and with the -g option. I now have some understanding of what is happening. As Eli correctly reasoned (without the benefit of an unstripped malloc and -g!!) one member of the linked list maintained by malloc/free points somewhere in the region of Mars. In terms of malloc's variables, op->ov_next = garbage so that when this member is handed out to the application dereferencing it causes the crash. I am currently using (learning) gdb to go through the code and will report progress if any. Thank you for your interest Gurunandan