> As you may have guessed, i wasn't able to replicate this...
> has anybody else tried it, and been 'successful'?
> 
> 
> chris
> 

Okay, here's more info but none of it very helpful :-(

I tried disabling external cache, cache shadow rom and
turbo.  The bug is still there and perfectly repeatable.

If I type
	cd /etc

	file /etc/*				Fine
	/usr/bin/file *				Fine
	file *					core dump
	file *					Fine!
	rm file.core
	file *					core dump
	rm file.core
	file [a-d]*				Fine!

This isn't from a script but I've run more than a few times :-)

GDB seems to be no use at all because it claims that the memory is
inaccessible and gives no useful backtrace.  It doesn't repeat if the
binary is compiled without -O, although -g has no effect.  Given the
finnicky behaviour in how it is called this probably doesn't imply a
compiler bug but then again how the hell would I know :-)

I thought that while I was logged in I could copy/paste the output from
gdb, unfortunately it now refuses to core dump because I'm running it
from an xterm (behaviour noted in the original msg) although it was
utterly repeatable before (from root login to console).


From inserting fprintf's it seems to crash _on_return_ from
tryit at line 245 of file.c.  I presume that the return link
is corrupted by a memory access made between the call and return.
There is an fprintf at the end of tryit which prints okay
but this one doesn't.

file.c: ~245
	else {
		buf[nbytes] = '\0';     /* null-terminate it */
		tryit(buf, nbytes);
		fprintf(stderr, "process 1z\n");
	}

The fact that it is so sensitive to changes inargv even
makes me think it is accessing a crazy bit of memory
indirectly that just occasionally catches its return link.

In summary, this is going to be a _tough_ bug to crack.
It probably isn't worth the effort.  I may look farther but
then again...

Have "Fun"

Bob



------------------------------------------------------------------------------