krono / squeaksource3

Seaside-based Monticello code repository for Squeak, Pharo and GemStone
0 stars 0 forks source link

stack overflow going off end of ancestor list #32

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
GemStone: Error         Nonfatal
GemStone Smalltalk execution stack overflow.
Error Category: 231169 [GemStone] Number: 2059 Arg Count: 1 Context : 1590798337

stack attached ... I'll provide more details in next comment

Original issue reported on code.google.com by henrichs...@gmail.com on 8 Oct 2011 at 4:01

Attachments:

GoogleCodeExporter commented 9 years ago
Start by clicking on the latest ConfigurationOftODE package in the Latest[1] 
category for the tODE project and then follow the Ancstor link back in time. 
When you hit ConfigurationOftODE-dkh.168 you are close to the trouble zone... 
keep hitting the ancestor links until the vm exits with a stack overflow ...

The problem doesn't always occur in the same place but once it does occur your 
session appears to be hosed as the stack overflows randomly occur until you 
acquire a fresh session ...

[1] http://ss3.gemstone.com/ss/tODE.html/Latest

Original comment by henrichs...@gmail.com on 8 Oct 2011 at 4:08

GoogleCodeExporter commented 9 years ago
I think the stacks are the same, but just in case I've enclosed another stack 
trace.

Original comment by henrichs...@gmail.com on 8 Oct 2011 at 4:11

Attachments:

GoogleCodeExporter commented 9 years ago
This one needs to be fixed

Original comment by henrichs...@gmail.com on 6 Dec 2011 at 11:40

GoogleCodeExporter commented 9 years ago
This is caused by the way Dynamic variables are implemented in Seaside, ie, as 
Exceptions.
Thread-local variables would be another, less stack intensive approach (as 
added recently to squeak).

Original comment by tobiasp...@gmail.com on 15 Dec 2011 at 2:29

GoogleCodeExporter commented 9 years ago
Could you describe the problem in a little more detail? I don't see how Dynamic 
variables are causing stack overflows.

Original comment by henrichs...@gmail.com on 15 Dec 2011 at 4:29

GoogleCodeExporter commented 9 years ago
Nevermind. I thought about the way Dynamic Variables are resolved, that is 
walking down and again up the stack using exceptions. However, looking at the 
trace again does not suggest that the Seaside Dynamic Variables cause the 
problem.

I now think this is caused just by the way Seaside works:
  When you are in the versions vi and click to go to the parent versions,
  Seaside internally uses a Delegation so you can go back laters:

                                                                                                                                           [Stack for parent version view]
                                                                                                                                           [           WADelegation            ]
                                                                 [Stack for parent version view]                            [Stack for parent version view]
                                                                 [           WADelegation            ]                            [           WADelegation            ]
[Stack for version view]  -{click parent}-> [      Stack for version view     ] 
-{click parent}-> [      Stack for version view     ]

If you click enoguh of the parent links, you'll end up eating up the stack.
This is no problem in Squeak/Pharo except in terms of memory but
can hit hard on gemstone

Original comment by tobiasp...@gmail.com on 26 Apr 2012 at 7:34

GoogleCodeExporter commented 9 years ago
The only solution I see, is to increase the GemStone stack.
It is a design limitation, as far as I can see.

Dale?

Original comment by tobiasp...@gmail.com on 5 Sep 2013 at 1:46