[ On Monday, March 18, 2002 at 19:26:57 (+0700), Robert Elz wrote: ]
> Subject: Re: xsrc/15357: stack trashing bug crashing the sparc Xservers 
>
>     Date:        Sun, 17 Mar 2002 17:22:30 -0500 (EST)
>     From:        woods@weird.com (Greg A. Woods)
>     Message-ID:  <20020317222230.E82898D@proven.weird.com>
> 
>   | However it would seem that between two lines of code a local pointer
>   | variable has suddenly changed value (in this case to zero!).  On line
>   | 1767 the value of 'grab' must have been non-zero,
> 
> Unless you show the assembler code, there's no evidence for that.

True enough, though I based my claim on the assumption that tempGrab, an
automatic structure variable, would have had all its fields initialised
to zero, and the assignment statement in which the first dereference of
'grab' occurs seems to have happened since there's a value now present
in the field in tempGrab that was assigned to.

> Sparc assembler isn't hard, but I'm afraid debugging X servers is outside
> my field.

I could post the disassembled function to this PR if it might help....

>   You might want to just make certain that you're not just
> reaching your stack size limit though.

Hmmm.... The Xserver runs as root.  I don't know what limits are forced
on it, but in an ordinary su session I see:

	# ulimit -a
	time(cpu-seconds)    unlimited
	file(blocks)         unlimited
	coredump(blocks)     unlimited
	data(kbytes)         65536
	stack(kbytes)        512
	lockedmem(kbytes)    12472
	memory(kbytes)       37416
	nofiles(descriptors) 64
	processes            256

Wouldn't a process exceeding the stack size limit always exhibit the
same kind of crash though (presumably SIGSEGV)?  I've had multiple
examples of each of SIGSEGV, SIGILL, and SIGBUS.


As a side note I should probably mention that since upgrading from
ctwm-3.5 to ctwm-3.5.2 my sessions seem to last longer and every core
dump since (two, IIRC, :-) have had complete stacks....

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>