[64bit] Problem with emacs and shared memory under X11
Ken Brown
kbrown@cornell.edu
Sat Jul 20 12:02:00 GMT 2013
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
Ken
More information about the Cygwin-apps
mailing list