This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: [64bit] Problem with emacs and shared memory under X11
- From: Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>
- To: cygwin-apps at cygwin dot com
- Date: Sat, 20 Jul 2013 13:30:44 -0400
- Subject: Re: [64bit] Problem with emacs and shared memory under X11
- References: <20130718083748 dot GA9628 at calimero dot vinschen dot de> <51E858E2 dot 7050802 at dronecode dot org dot uk> <20130718213455 dot GC30542 at calimero dot vinschen dot de> <51E91378 dot 6060402 at dronecode dot org dot uk> <20130719113509 dot GF20871 at calimero dot vinschen dot de> <51E96374 dot 4080308 at cornell dot edu> <20130719171104 dot GI20871 at calimero dot vinschen dot de> <51E974D9 dot 30906 at dronecode dot org dot uk> <20130720050608 dot GA4134 at ednor dot casa dot cgf dot cx> <51EA7C58 dot 8040307 at cornell dot edu>
- Reply-to: cygwin-apps at cygwin dot com
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