This is the mail archive of the cygwin-apps 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: [64bit] Problem with emacs and shared memory under X11

On 7/20/2013 1:30 PM, Christopher Faylor wrote:
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

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


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.

Sorry, I didn't test the latest snapshot on x86_64 because I didn't realize anything had changed there. I was comparing the current snapshot on x86 to the previous snapshot on x86_64.

Anyway, the main thing is that the bug is fixed.  Thanks.


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