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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.1.0-0.1


On 7/1/2015 4:12 PM, Ken Brown wrote:
On 7/1/2015 9:57 AM, Corinna Vinschen wrote:
On Jul  1 12:47, Corinna Vinschen wrote:
On Jun 30 16:13, Ken Brown wrote:
On 6/30/2015 3:55 PM, Corinna Vinschen wrote:
On Jun 27 16:52, Corinna Vinschen wrote:
On Jun 26 18:28, Ken Brown wrote:
On the other hand, emacs doesn't really make a full recovery.  For example,
if I try to call a subprocess (e.g., 'C-x d' to list a directory), I get a
fork error:

Debugger entered--Lisp error: (file-error "Doing vfork" "Resource
temporarily unavailable")
[...]
Just FYI, I don't know yet what happens exactly, but this has nothing
to do with the alternate stack.  The child process fails with a status
code 0xC00000FD, STATUS_STACK_OVERFLOW.  Which is kind of weird, given
that the stack overflow has been averted by calling siglongjmp.

I have a hunch.  The stack state in the parent is so that TEB::StackLimit
points into the topmost guard area which, when poked into, triggers the
stack overflow exception.  When forking, Cygwin performs exactly this:
It pokes into the stack to push the guard page out of the way, thus
causing the stack memory to be commited, which in turn allows to copy
the stack content from parent to child.

Ok, I'm not sure if I can debug this soon, but at leats it's not
related to sigaltstack handling nor is it a regression.

Thanks for the info, that's good to know.  Just out of curiosity, were you
able to modify your testcase for this, or did you test with emacs?

I just added a fork call to my testcase right after the last printf.

My hunch was correct, apparently.  I changed the way the stack info
is set up for the child so only the actually used part of the stack is
prepared for the stack copy in the child.  This not only avoids the
stack overflow in the child, it should shave a few nanoseconds from
the time a fork takes ;)

I uploaded new developer snapshots to https://cygwin.com/snapshots/ and
I'm just building and uploading a new test release.

Please give it another try.

That fixes it.  Thanks!

I may have spoken too soon. As I repeat the experiment on a different computer, with a build from a slightly different snapshot of the emacs trunk, emacs crashes when I type 'C-x d' with the following stack dump:

Stack trace:
Frame        Function    Args
00100A3E240  00180071CC3 (00000829630, 000008296D0, 00000000000, 0000082CE00)
00030000002  001800732BE (00000000000, 00000000002, 00100A48C80, 00000000002)
00000000000  00000006B40 (00000000002, 00100A48C80, 00000000002, 00100A48768)
00000000000  21000000003 (00000000002, 00100A48C80, 00000000002, 00100A48768)
End of stack trace

$ addr2line 00180071CC3 -e /usr/lib/debug/usr/bin/cygwin1.dbg
/usr/src/debug/cygwin-2.1.0-0.3/winsup/cygwin/exception.h:175

$ addr2line 001800732BE -e /usr/lib/debug/usr/bin/cygwin1.dbg
/usr/src/debug/cygwin-2.1.0-0.3/winsup/cygwin/exceptions.cc:1639

The next two days are pretty busy for me, but I'll try to provide further information as soon as I have a chance.

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


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