[Pnet-developers] The stack trace bug revisited

[Gopal V]

Some time ago , Rhys Weatherley wrote this:
> triggers on your machine due to differences in the compiler.  I can't
> reproduce it here, so I hope that you can track it down.  Setting a

Ok, so here is the bug I'm faced with ... it has something to do with
the empty try {} catch{} in the method .... Possibly (I hazard a guess) , 
the try offsets are overflowing , jumping to the non-existent handler
and rethrowing the exception ?. 

Returning to NumberParser::ParseNumber (35)
Stack: 0x8114E04 0x0 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x401D7471:  set_stack_trace     
0x401D7473:  throw_caller        
Throw Caller Stack: 0x8114E04 0x0 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x0 0x0 0x0 0x0 
0x0 0x0 0x0
Throwing Back To NumberParser::ParseInt32
Throwing Back To Int32::Parse
Throwing Back To Int32::Parse
Throwing Back To One::CallIntParse
Throw Stack: 0x8114E04 0xA
0x401D2093:  set_stack_trace     
0x401D2095:  throw_caller        
Throw Caller Stack: 0x8114E04 0xA
Throwing Back To One::Main

it is the second set_stack_trace that I don't like .... why should it 
catch something there ?.

Also I'm removing the skipframes hack from engine/lib_diag.c now that
we don't need it ..

This one has been irritated me a lot when I was debugging Jabber.net ...

But, if you really want some fun , try putting something in a Finalize()
or destructor .. watch it pop up suddenly out of the blue and crash the 
entire system :-) And then , try reading *that* stacktrace !

Gopal
-- 
The difference between insanity and genius is measured by success

tracebug.cs
Description: Text document