Stack overflow exception

[jbix]

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
"jb**@newsgroups.nospam" <Mr. Bix> wrote in message
news:52**********************************@microsof t.com...

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?

[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.

--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...
http://tinyurl.com/27cok
"jb**@newsgroups.nospam" <Mr. Bix> wrote in message
news:52**********************************@microsof t.com...

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?

[Mr Bix]

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
"jb**@newsgroups.nospam" <Mr. Bix> wrote in messag
news:52**********************************@microsof t.com..

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

Is there a way to monitor the stack size at runtime to see if we can catc

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 Does the GC run while in debug

[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.

"Mr Bix" <an*******@discussions.microsoft.com> wrote in message
news:8B**********************************@microsof t.com...

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 catch
the error?

Our 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 wrote: -----

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
"jb**@newsgroups.nospam" <Mr. Bix> wrote in message
news:52**********************************@microsof t.com...

> 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?

[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

"jb**@newsgroups.nospam" <Mr. Bix> wrote in message
news:52**********************************@microsof t.com...

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?