On Feb 27 17:17, Corinna Vinschen wrote: > On Feb 27 16:38, E. Madison Bray wrote: > > Hello, > > > > A very technical request regarding Cygwin internals: In mmap.c there > > is a function mmap_is_attached_or_noreserve(void *addr, size_t len) > > which is called from Cygwin's exception handler in the case of a > > STATUS_ACCESS_VIOLATION. > > > > This is called in case an access violation occurs in memory that was > > allocated with Cygwin's mmap() with the MAP_NORESERVE flag, and allows > > us to commit the relevant pages when they are accessed. > > > > After a successful call of mmap_is_attached_or_noreserve(), the Cygwin > > exception handler returns with ExceptionContinueExecution. > > Unfortunately, if the application happens to have a Vectored Continue > > Handler registered which happens to do something in the case of > > STATUS_ACCESS_VIOLATION (see [1]) there is no obvious way to tell if > > we're handling this sort of case. > > > > Normally this isn't too much of a problem: E.g. we could just check > > the address that caused the access violation and see if its status is > > now MEM_COMMIT (i.e. Cygwin ran its exception handler and all is > > good). However, due to the bug described in [1], if an exception > > occurs in code running on a sigaltstack, the Cygwin exception handler > > isn't run. > > > > This makes for a tricky to handle use case: What if some code in a > > signal handler function tries to access uncommitted memory in a > > MAP_NORESERVE mmap? It's probably an unusual, undesirable case, and I > > haven't personally encountered it *yet*, but I could imagine some > > cases where it might happen. > > > > In order to handle such a case it might be nice if > > mmap_is_attached_or_noreserve were able to be called by user code, > > perhaps as a new cygwin_internal(...) call. I'd happily provide a > > patch, but I fear this might be an X/Y problem that I'm not seeing. > > Honestly, I'm not overly keen to expose this stuff. Wouldn't it > make more sense to fix Cygwin's sigaltstack implementation to handle > these cases gracefully? You're apparently not shy working with > Windows exception handling. Patches more than welcome! I'm not > happy not having found a solution to this problem :} Oh, wait! Maybe there is a simple solution. Patch 9a5abcc896bd added a single line exception protect; to the pthread::thread_init_wrapper method. What if adding the same line to the altstack_wrapper function would help for altstack as well? Can you test this? Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer