Open GoogleCodeExporter opened 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
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:
This one needs to be fixed
Original comment by henrichs...@gmail.com
on 6 Dec 2011 at 11:40
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
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
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
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
Original issue reported on code.google.com by
henrichs...@gmail.com
on 8 Oct 2011 at 4:01Attachments: