Re: Help: Unwinding the C++ stack...throw, longjmp & threads

[Josh Stern <jstern at citilink dot com>]

Josh writes:                                            
> I would diagnose the problem above as an inadequate implementation     
> of malloc() (relative to use in a program that could throw from    
> a signal handler).                                                      
                                                                         
>No, you are thinking of malloc corruption, which is not the issue here.   
>Assume a perfect implementation, with proper critical regions in malloc     
>(sighold/sigrelease or the like).  If buf is in memory -- more likely if

>there is still a window between the return of malloc (the end of any      
>critical region) and the assignment of the result.  Even if buf is a  
>register, we may still need a reg-to-reg move, and the signal could     
>come just before the move. 

Of course the chance of getting a signal that you want to throw on
just as malloc() returns, combined with the situation where you
actually care about the memory leak at this juncture, combined
with the situation where the last catch that is released isn't
going to just free a whole epoch of allocations, is an
extremely low probability circumstance.  I understood the
example but thought of this case as being lost in the 'noise'.

To deal with such a case I would design the malloc in such a 
way that it assigns the last allocation to a private/static 
pointer (possibly set up to use per thread storage, if that's relevant) 
prior to malloc returning, and  I would also provide an
interface to retrieve this ptr (which is not otherwise used),
so that if I am doing a large allocation in a critical program,
the the updated version of the exception handler that you wrote
eawould retrieve the ptr through the interface and
delete it in the case of finding that 'ptr' or
'somestructure->buf' had received a NULL allocation.


- Josh