Re: Scheduler Core Dump

[Matti Aarnio <mea@nic.funet.fi>]

> Greetings:
> 
> 	Has anyone seen this type of core dump before ...
> 
> --------------------------------------
> 
> There is absolutely no warranty for GDB; type "show warranty" for details.
> GDB 4.12 (sparc-sun-solaris2.3), 
> Copyright 1994 Free Software Foundation, Inc...
> Core was generated by `/usr/local/mail/bin/scheduler -s -N 128'.
> Program terminated with signal 10, Bus error.
> procfs (find_procinfo):  Couldn't locate pid 0
> |#0  0x1a69c in expaux (vp=0x1339f0, index=67, 
> |    buf=0x3482b8 "\rexpired after 3 days, problem was:\r500 (write to server err
> |or: Broken pipe)") at update.c:497

	Yes, that is indicative of an error in memory-block reuse.
	SPARC will not like to access longwords from non-aligned addresses,
	and thus will trap it via SIGSBUS

	As to WHY it happened, UofToronto malloc (malloc_d) does fill
	all freed memory blocks with 0x55, which can become interpreted
	as a pointer -> unalignment -> SIGBUS..

	I have been trying to use ElectricFence (ftp.pixar.com:/pub/bruce/)
	to debug memory access bugs, but when using it in EF_PROTECT_FREE
	(or something like that) -mode, the SunOS library routines
	cause it to crash..  Ah well :-/  (gethostnyname(), among others..)

> |497                 msgerror(vp, vp->cfp->offset[index], buf);
> |(gdb) bt
> |#0  0x1a69c in expaux (vp=0x1339f0, index=67, 
> |    buf=0x3482b8 "\rexpired after 3 days, problem was:\r500 (write to server err
> |or: Broken pipe)") at update.c:497
> |
> /mh
> 


	/Matti Aarnio