This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Consider exposing mmap_is_attached_or_noreserve


On Feb 28 12:50, E. Madison Bray wrote:
> On Wed, Feb 27, 2019 at 5:17 PM Corinna Vinschen wrote:
> >
> > On Feb 27 16:38, E. Madison Bray wrote:
> > > 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 :}
> 
> I can theoretically imagine a case where might be a problem totally
> outside the context of the altstack issue: e.g. maybe a cygwin
> application that has to link with a native Windows DLL that happens to
> register some vectored continue handler that does something with
> STATUS_ACCESS_VIOLATION exceptions.  Of course, absent a real example
> I wouldn't push for it.

A Cygwin application creating a vectored exception handler is not really
a Cygwin application since that circumvents Cygwin's exeception and
signal handling.  Even if Cygwin's handling isn't entirely foolproof,
that's a slippery slope.

> I completely agree it would be better to have a solution to the actual  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?
> 
> You know, I actually noticed this just recently, because I noticed
> that pthreads also run on a stack allocated by Cygwin, and I wondered
> how exception handling would work in that case.  I think I was looking
> at it in the context of the thread last month that resulted in that
> fix, but I forgot to ask you if this could work for the altstack issue
> as well.

No worries, we can't fix all problems at one :}

> > Can you test this?
> 
> I'll give it a try and report back with a patch if it works.

That would be way cool.  I'm looking forward to it.

> The biggest risk is if a stack overflow happens while running on the
> altstack--in this case even the Cygwin exception handling could fail
> and the application will just crash.  But for other, less extreme
> cases having this would be better than nothing.

Stack overflow is nasty.  You're aware of the special concession for
this case in altstack_wrapper(), right?  It's not exacly what happens
on Linux, but it's at least some clean way out.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

Attachment: signature.asc
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]