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.4


On 7/5/2015 5:34 PM, Corinna Vinschen wrote:
This test release needs some good testing!

I repeated the emacs experiment discussed in the "[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.1.0-0.1" thread. In the 32-bit case, the results were more-or-less the same as before: I forced a stack overflow, emacs recovered, I tried to continue working, there was a second SIGSEGV, and handle_sigsegv bailed out because garbage collection was in progress. This time I was unable to prevent the second SIGSEGV by resetting max-specpdl-size and max-lisp-eval-depth. I'm not sure what caused the second SIGSEGV, but it might have nothing to do with Cygwin.

In the 64-bit case, however, the recovery from stack overflow never happened (i.e., the program never reached the siglongjmp). Here's a gdb session:

$ gdb ./emacs.exe
[...]
(gdb) b handle_sigsegv
Breakpoint 3 at 0x1005657b3: file ../../master/src/sysdep.c, line 1643.
(gdb) r -Q
Starting program: /home/kbrown/src/emacs/64build/src/emacs.exe -Q
[At this point I force stack overflow.]

Program received signal SIGSEGV, Segmentation fault.
0x000000010053b08b in builtin_lisp_symbol (index=290)
    at ../../master/src/lisp.h:1069
1069      return make_lisp_symbol (lispsym + index);
(gdb) c
Continuing.

Breakpoint 3, handle_sigsegv (sig=11,
    siginfo=0x100a3e190 <sigsegv_stack+65232>, arg=0x82de50)
    at ../../master/src/sysdep.c:1643
1643      if (!gc_in_progress)
(gdb) l
1638    static void
1639    handle_sigsegv (int sig, siginfo_t *siginfo, void *arg)
1640    {
1641      /* Hard GC error may lead to stack overflow caused by
1642         too nested calls to mark_object.  No way to survive.  */
1643      if (!gc_in_progress)
1644        {
1645          struct rlimit rlim;
1646
1647          if (!getrlimit (RLIMIT_STACK, &rlim))
(gdb)
1648            {
1649    #ifdef CYGWIN
1650              enum { STACK_DANGER_ZONE = 32 * 1024 };
1651    #else
1652              enum { STACK_DANGER_ZONE = 16 * 1024 };
1653    #endif
1654              char *beg, *end, *addr;
1655
1656              beg = stack_bottom;
1657              end = stack_bottom + stack_direction * rlim.rlim_cur;
(gdb)
1658              if (beg > end)
1659                addr = beg, beg = end, end = addr;
1660              addr = (char *) siginfo->si_addr;
1661              /* If we're somewhere on stack and too close to
1662                 one of its boundaries, most likely this is it.  */
1663              if (beg < addr && addr < end
1664                  && (addr - beg < STACK_DANGER_ZONE
1665                      || end - addr < STACK_DANGER_ZONE))
1666                siglongjmp (return_to_command_loop, 1);
1667            }
(gdb) n
1647          if (!getrlimit (RLIMIT_STACK, &rlim))
(gdb)
1656              beg = stack_bottom;
(gdb)
1657              end = stack_bottom + stack_direction * rlim.rlim_cur;
(gdb)
1658              if (beg > end)
(gdb)
1660              addr = (char *) siginfo->si_addr;
(gdb)
1663              if (beg < addr && addr < end
(gdb) p beg
$1 = 0x82ca27 ""
(gdb) p addr
$2 = 0x33ff8 ""

Note that addr < beg, so we never reach the siglongjmp.

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]