On Sat, Jul 20, 2013 at 08:02:32AM -0400, Ken Brown wrote: >On 7/20/2013 1:06 AM, Christopher Faylor wrote: >> On Fri, Jul 19, 2013 at 06:18:17PM +0100, Jon TURNEY wrote: >>> On 19/07/2013 18:11, Corinna Vinschen wrote: >>>> On Jul 19 12:04, Ken Brown wrote: >>>>> On 7/19/2013 7:35 AM, Corinna Vinschen wrote: >>>>>> On Jul 19 11:22, Jon TURNEY wrote: >>>>>>> Oh yes, that works, and is a bit clearer. >>>>>> >>>>>> Thanks for testing. I applied the patch and attributed it to you in >>>>>> the ChangeLog since you did all the work anyway. >>>>> >>>>> There's still the x86 issue that I mentioned earlier. With >>>>> cygwin-1.7.21 (as well as today's snapshot), I'm getting a return >>>>> value of 0 from shmtest on x86. This is with cygserver not running. >>>>> (In fact, cygserver has never been configured on this system, so >>>>> there's no /etc/cygserver.conf). Jon reported getting a return >>>>> value of 1 using cygwin-1.7.20. >>>> >>>> I don't recall seeing this testcase. Any chance you can extract an STC >>>> to help fixing this? I wonder how this happened anyway. There were no >>>> changes in terms of XSI IPC between 1.7.20 and 1.7.21, except for tiny >>>> changes for porting to x86_64. What on earth did I screw up this >>>> time?!? >>> >>> shmtest.c was attached to my mail a couple of days ago [1] >>> >>> This seems to be an unrelated issue. When cygserver is not running, this >>> program should receive a SIGSYS and terminate with exit code 140 (128 + >>> signal) >>> >>> This works correctly on x86_64, but on x86, although the signal is raised, >>> something goes wrong and the exit code is 0... >>> >>> [1] http://cygwin.com/ml/cygwin-apps/2013-07/msg00229.html >> >> The exit 0 behavior (which I think was introduced in 1.7.20) should now >> be fixed in CVS and, soon, in a snapshot. > >Confirmed. I now get "Bad system call", as expected, and an exit code >of 140. This is from running shmtest with cygserver not running. > >There's still a difference between the x86 behavior and the x86_64 >behavior. It's not relevant to the bug being discussed in this thread, >and maybe it's to be expected, but I'll report it anyway: > >On x86_64 the error message is "Bad system call (core dumped)", and >there is in fact a stackdump. On x86 the error message doesn't say >"core dumped", but there is nevertheless a stackdump file created, which >is essentially empty: > >$ cat shmtest32.exe.stackdump >Stack trace: >Frame Function Args
Actually, with the latest snapshot you should have seen no "core dumped" for either x86 or x86_64. Corinna and I noted that this behavior was inconsistent with Linux. However, after further discussion, I have reverted that particular change. AFAICT, getting a valid stackdump in this scenario is problematic for x86 and nearly impossible for x86_64. Newer compilers now default to -fomit-frame-pointer (x86_64 always did this) so Cygwin's "generate a stack dump" facility is likely going to be less and less useful over time. cgf
