Replying under a different subject line in hopes of reattaching to
the thread in BFAV.

Hi Doug,

I have not reconstructed from old images, but my best guess is that
the bug entered the image with the Project class>>interruptName:
method, which is time stamped 9/5/2001. The bug was present at that
point, but was not manifested until someone else added a high priority
background process into the system, which just happened to be the
otherwise blameless EventTickler process (EventSensor>>eventTickler),
which runs all the time at lowIOPriority. This was introduced in
update 5000 in April 2004, so I would expect that people started
noticing the problem after that time.

The current thread in BFAV dates back to September 2003, which
suggests that the symptoms of this problem were being seen before
the EventTickler was introduced (or maybe I just did not follow
the trail all the way back). So I'm not entirely sure how long
people have been seeing symptoms of the problem. I'm reasonably
sure (call it about 90% confidence level, gut feel) that the
bug/fix that I posted addresses the underlying issue, although
I would not be surprised if it turns out that there are other
lurking buglets that might lead to similar symptoms.

Important: This one is timing-dependent, and you may see different
symptoms depending on the VM and any memory settings you may have
used on the command line. On my Linux system, if I force a limit
on the amount of memory used (with "squeak -memory 10m"), I end
up with a real VM crash, stack dump and all. If I don't limit the
memory (which would be the normal mode of use), the image just
becomes unresponsive when it gets into an infinite recursion, and
cannot be interrupted. Presumably the VM is busy trying to allocate
more memory from the OS, but does not actually crash while it's
chewing away on this problem.

I thought that I had read an earlier report that (John's) Mac
OS X does not exhibit the problem, apparently due to its use of
a threaded VM that is more responsive to UI events. However, your
description of the behavior on your OS X system sounds quite similar
to what I see on Linux. 

RiscOS seems to behave similarly to Linux, and I don't know what
Windows does.

Hope this helps,

Dave

On Tue, Jun 15, 2004 at 12:35:20AM -0400, Doug Way wrote:
> 
> On Monday, June 14, 2004, at 10:21 PM, David T. Lewis wrote:
> 
> > On Mon, Jun 14, 2004 at 02:23:59AM -0400, dway at mailcan.com wrote:
> >>
> >> Last batch for 3.7beta (barring any major bugfixes appearing).
> >
> > It's too late in the release cycle for 3.7, but doesn't anybody 
> > consider
> > "[bug][FIX] stack overflow crashes Squeak" to be a major bug? Reviewers
> > needed. Thanks!
> 
> I just spent a bit of time trying to figure out when this bug 
> appeared...
> 
> First, I'm running 3.7beta on Mac OS X (10.2.5) with the 3.7.1Beta2 
> carbon VM.  If I run "Smalltalk createStackOverflow" I can break out of 
> it via cmd-. during the first several seconds, but if I let it run a 
> few minutes, that doesn't work.  Although even after letting it run 10+ 
> minutes, Squeak never crashes, it just runs the CPU, and the low space 
> watcher never comes up.
> 
> Running the unix "top" command, the space alloted to the VM (VSIZE) is 
> 555MB when starting Squeak, which does not change while it runs.  
> (RPRVT and RSIZE creep up very slowly)
> 
> I see exactly the same behavior on a 3.6-5429-basic image with the 
> 3.7.1Beta2 VM, and the same behavior again with the 3.2final image and 
> the 3.2 VM.  So, I'm not sure how new the problem is...
> 
> - Doug
>