Ok, so the break is in this 'memcpy' - which the compiler has inlined
to a single 'mov' instruction (at sysctl_procargs+0x1fd):

> /usr/src/sys/arch/i386/compile/CRASH/../../../../kern/kern_sysctl.c:2126
> 	case KERN_PROC_ARGV:
> 		/* XXX compat32 stuff here */
> 		memcpy(&tmp, (char *)&pss + p->p_psargv, sizeof(tmp));
> c030f590 <sysctl_procargs+0x1f4> 8b 7d bc             	mov    0xffffffbc(%ebp),%edi
> c030f593 <sysctl_procargs+0x1f7> 8b 87 7c 01 00 00    	mov    0x17c(%edi),%eax
> c030f599 <sysctl_procargs+0x1fd> 8b 44 28 f0          	mov    0xfffffff0(%eax,%ebp,1),%eax
> /usr/src/sys/arch/i386/compile/CRASH/../../../../kern/kern_sysctl.c:2127
> 		break;

Now we don't have the registers of the panic (anyone fancy fixing ddb?)
but the above should have extreme difficulty in exploding.

p->p_psargv is a constant - I think it should be 0 for all processes
and all the time.  The only time it will be wrong (for a pointer that
has been a valid proc pointer) is if the process has exited and the
memory page released from the pool back for general use.

Any thoughts?

I don't see any need for p->p_psargv and friends - but I can't quite
see how the value read can be invalid - even though it must be!

OTOH this code is completly borked should the process actually exit!

	David

-- 
David Laight: david@l8s.co.uk