* Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:

> I guess also, as you suggested elsewhere in this thread, I could try 
> an 8K stacks kernel, let openvpn run (even just for 5 minutes, then 
> close it) and see if I get a stack-footprint dump *for openvpn*, which 
> so far I've not been able to observe.
> 
> Hopefully this would negate the possibility that there's a 
> stack-footprint waiting to be generated, but just masked by the crash.

indeed, you are right. I think we can exclude the stack-overflow for 
now. (also, the likelyhood of it not being detected and printed in a 
safe manner as it happens is very low. We do a stack-overflow test for 
every function entered, and the threshold is 1024 bytes - more than the 
biggest (realistic) offenders could cause.)

> Is this actually useful to you?

yeah. You are triggering a type of crash that is hard to debug. Those 
are always important to track down, so that we can see whether the debug 
infrastructure can be improved to make the debugging process much 
quicker. Next time such a bug could be sporadic, making it close to
impossible to debug.

if you still have some debugging stamina left then i'd now suggest to 
try an 'all debugging options enabled' (including the enabling 
DEBUG_STACK_POISON in kernel/latency.c) run with the latest -51-20 
kernel. I've attached a .config with all the debug options set that may 
matter - it should be ready-to-use for you.

	Ingo