Stack overflow exception

[Guest]

We have a stack overflow happening. We are NOT doing any recusion. We do have an object being created in Global that is being handed the Context (which I assume is specific to the request thread). This object does in turn does create several other objects, but therer is no memberwise cloning or deep copies. So, we are at a loss why we are running out of stack so early.

Is there a way to monitor the stack size at runtime to see if we can catch the error?
Is it unwise to create objects in Global? Is this somehow creating many objects in the pipeline?
Out undstanding is a set of objects created in a request thread are bound to that request and are deleted at the end of the request thread?
Does the GC run while in debug?

 

[Martin Dechev]

Hi,

In 99.9% of the cases stack overflow is because of an error in the code. But
without seeing any of your code I'm afraid it is not possinble to tell you
more.

Greetings
Martin

We have a stack overflow happening. We are NOT doing any recusion. We do

have an object being created in Global that is being handed the Context
(which I assume is specific to the request thread). This object does in
turn does create several other objects, but therer is no memberwise cloning
or deep copies. So, we are at a loss why we are running out of stack so
early.

Is there a way to monitor the stack size at runtime to see if we can catch the error?
Is it unwise to create objects in Global? Is this somehow creating many objects in the pipeline?
Out undstanding is a set of objects created in a request thread are bound

to that request and are deleted at the end of the request thread?

 

[Alvin Bruney [MVP]]

Can you reproduce the error at will in a debugger environment? If yes, press
CTRL + ALT + E, set it to break into the debugger on all exceptions and let
the application run to reproduce the bug. The exception will stop at the
offending line of code. That's the easy part. Writing robust code is what is
difficult.

 

[Guest]

Ok...I understand your overall answer, but....

I am still curious about
Is there a way to monitor the stack size at runtime to see if we can catc
the error

Our undstanding is a set of objects created in a request thread are boun
to that request and are deleted at the end of the request thread

Does the GC run while in debug


----- Martin Dechev wrote: ----

Hi

In 99.9% of the cases stack overflow is because of an error in the code. Bu
without seeing any of your code I'm afraid it is not possinble to tell yo
more

Greeting
Marti

We have a stack overflow happening. We are NOT doing any recusion. We d

have an object being created in Global that is being handed the Contex
(which I assume is specific to the request thread). This object does i
turn does create several other objects, but therer is no memberwise clonin
or deep copies. So, we are at a loss why we are running out of stack s
early

the error
Is it unwise to create objects in Global? Is this somehow creating man objects in the pipeline
Out undstanding is a set of objects created in a request thread are boun

to that request and are deleted at the end of the request thread

 

[Kevin Spencer]

Hi Mr Bix,

I may be able to be of a little more help here. Stack Overflows are almost
always caused by either infinte looping or infinite recursion. So, check
your loops, and if you have any recursive functions, check them too.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

 

[Rick Spiewak]

Is it possible that a property setter or getter in your object is
inadvertantly referring to itself (not that I've ever done this <g>).
i.e. -
Private _foo as object
Public Property Foo() as object
Get
Return Foo 'should be Return _foo
End Get
..
..
..

End Property

We have a stack overflow happening. We are NOT doing any recusion. We do

have an object being created in Global that is being handed the Context
(which I assume is specific to the request thread). This object does in
turn does create several other objects, but therer is no memberwise cloning
or deep copies. So, we are at a loss why we are running out of stack so
early.

Is there a way to monitor the stack size at runtime to see if we can catch the error?
Is it unwise to create objects in Global? Is this somehow creating many objects in the pipeline?
Out undstanding is a set of objects created in a request thread are bound

to that request and are deleted at the end of the request thread?