RE: 'thread stack pointer out of range'?

["Boehm, Hans" <hans_boehm at hp dot com>]

I'm open to suggestions as to what to do here.  My impression was that the issue is mostly with third-party (not necessarily Microsoft) libraries that decide to use the stack pointer as a temporary register for the duration of some inner loop.

I have no idea whether there's really much danger of the stack pointer being wrong, but not detectably so.   It doesn't seem to be the common scenario.  Working around it seems hard.  The "out of range" esp value (or the corresponding pc value) is obtained from GetThreadContext when the world is already half stopped.  You could try to give up and restart it if you don't like the pc value.  But I'm not sure how you recognize that the pc is in a hand-coded routine that might mess with the sp.

It may be that the best we can do is to make sure that we don't abuse the sp (which may also help debugging and reliability), perhaps handle the case of an obviously bad sp, and wrap known instances of routines that mess with the sp.  Can you look at the failure case with a debugger?  At the failure point, thread_table[i].context should contain the context of the offending thread, presumably including its pc.

There currently isn't a good hook for wrapping suspicious calls.  In the nonincremental case, it's possible to prevent collection by setting GC_dont_gc.  In the incremental case, you would first have to wait for an ongoing one to finish.  There's a routine to do that, but it's not exported, and not always linked in.  One would also have to be careful that you couldn't get unbounded heap growth by consistently turning off GC at the wrong points, and that the wrapped routines can't block.

Hans


> -----Original Message-----
> From: Adam Megacz [mailto:gcj@lists.megacz.com]
> Sent: Tuesday, June 25, 2002 12:13 PM
> To: Boehm, Hans
> Subject: Re: 'thread stack pointer out of range'?
> 
> 
> 
> "Boehm, Hans" <hans_boehm@hp.com> writes:
> > The problem apparently is that in a few cases win32 library calls
> > abuse the sp register for something else, causing the collector to
> > see a bad stack pointer value.
> 
> Ugh, so I take it this happens if one thread is inside an API call and
> another thread tries to allocate memory, thereby triggering the
> collector?
> 
> > If the stack pointer is completely out of range, this can be worked
> > around by scanning the entire stack segment.  I don't know what to
> > do if it's just a little off.
> 
> Hrm. Okay. I'd like to fix this on the branch if possible -- as a
> temporary hack, is there some way I can put a shield around the Win32
> API calls in libgcj telling the collector not to run if some thread is
> inside an API call? This is ugly and will hurt performance, but I
> think it's worth it for correctness.
> 
> Is there a Win32 API function to query the pc of another thread?
> Perhaps this would be useful -- if another thread is outside the
> program's code segment(s), defer collection, since we might be inside
> an abusive API call.
> 
> Also, can we take this discussion onto the java@gcc.gnu.org list?
> 
>   - a
> 
> -- 
> Sick of HTML user interfaces?
> www.xwt.org
> 
> "disappointing retail sales figures suggest to some that 
> America's love
>  affair with retail therapy may be over."    -- _The 
> Economist_, 19-Jun
>