Mail Archives: djgpp/1998/08/04/03:04:01
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
- Raw text -