GNU bug report logs - #35204
27.0.50; Crash on Cygwin

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 35204 in the body.
You can then email your comments to 35204 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; Crash on Cygwin
Date: Tue, 09 Apr 2019 17:07:58 +0900

Hi,

Recently Emacs on Cygwin suddenly crashes while it is (probably)
in idle, only it lives for several minuits, but reverting the
following three changes seems to help.

1. commit 0b8117ed1abfc17bb0bc1690a8997736f1e8f98c
    ; * src/frame.h (MonitorInfo): Remove const modifier
2. commit 7b78857c0ba69eafd780484641b858ae8a167044
    ; * src/xfns.c (x-display-monitor-attributes-list) Fix typo.
3. commit a35e06bbe27c5907f56c5aeb48182d7be00d1dec
    Plug memory leak in GTK x-display-monitor-attributes-list
    * src/frame.c (free_monitors) [USE_GTK]: Define in the GTK case as
      well.
    * src/xfns.c (x-display-monitor-attributes-list) [USE_GTK]: Plug
      memory leak.
    * src/frame.h (MonitorInfo): Declare name as pointing to const char.

I'm not sure what to do but please tell me anything I should do.

In GNU Emacs 27.0.50 (build 3, x86_64-pc-cygwin, GTK+ Version 3.22.28)
 of 2019-04-09 built on localhost
Windowing system distributor 'The Cygwin/X Project', version 11.0.12004000

Configured using:
 'configure CFLAGS=-O0 --verbose --with-x-toolkit=gtk3'

uname -a
CYGWIN_NT-10.0 localhost 3.0.6(0.338/5/3) 2019-04-06 16:18 x86_64 Cygwin


Here is a gdb backtrace I got after reverting only 1.:

(gdb) bt
#0  0x000000010054a66a in terminate_due_to_signal ()
#1  0x000000010057110d in handle_fatal_signal ()
#2  0x00000001005710e0 in deliver_thread_signal ()
#3  0x0000000100571149 in deliver_fatal_thread_signal ()
#4  0x0000000100571361 in handle_sigsegv ()
#5  0x000000018005f65a in altstack_wrapper (sig=<optimized out>, 
    siginfo=<optimized out>, sigctx=0xffffde50, 
    handler=0x1005712a5 <handle_sigsegv>)
    at /usr/src/debug/cygwin-3.0.6-1/winsup/cygwin/exceptions.cc:1595
#6  0x0000000180062dfa in _cygtls::call_signal_handler (this=0xffffce00)
    at /usr/src/debug/cygwin-3.0.6-1/winsup/cygwin/exceptions.cc:1777
#7  0x0000000000000000 in ?? ()

I couldn't fetch a backtrace for Emacs before reverting because
of an error:

(gdb) bt
#0  0x000000010054a72f in terminate_due_to_signal ()
#1  0x000303e90000faf0 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Couldn't fetch xbacktrace either:

(gdb) source .gdbinit
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
DISPLAY = :0.0
TERM = xterm
Breakpoint 1 at 0x10054a66a
.gdbinit:1228: Error in sourced command file:
No symbol "defined_HAVE_X_WINDOWS" in current context.

Thanks.
Regards,

Message #8 received at 35204 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Katsumi Yamaoka <yamaoka <at> jpl.org>
Cc: 35204 <at> debbugs.gnu.org
Subject: Re: bug#35204: 27.0.50; Crash on Cygwin
Date: Tue, 09 Apr 2019 12:47:52 +0300

> Date: Tue, 09 Apr 2019 17:07:58 +0900
> From: Katsumi Yamaoka <yamaoka <at> jpl.org>
> 
> Here is a gdb backtrace I got after reverting only 1.:
> 
> (gdb) bt
> #0  0x000000010054a66a in terminate_due_to_signal ()
> #1  0x000000010057110d in handle_fatal_signal ()
> #2  0x00000001005710e0 in deliver_thread_signal ()
> #3  0x0000000100571149 in deliver_fatal_thread_signal ()
> #4  0x0000000100571361 in handle_sigsegv ()
> #5  0x000000018005f65a in altstack_wrapper (sig=<optimized out>, 
>     siginfo=<optimized out>, sigctx=0xffffde50, 
>     handler=0x1005712a5 <handle_sigsegv>)
>     at /usr/src/debug/cygwin-3.0.6-1/winsup/cygwin/exceptions.cc:1595
> #6  0x0000000180062dfa in _cygtls::call_signal_handler (this=0xffffce00)
>     at /usr/src/debug/cygwin-3.0.6-1/winsup/cygwin/exceptions.cc:1777
> #7  0x0000000000000000 in ?? ()

Is this when you run Emacs from GDB to begin with?  If not, please run
Emacs from GDB, then the backtrace should be more informative.

> I couldn't fetch a backtrace for Emacs before reverting because
> of an error:
> 
> (gdb) bt
> #0  0x000000010054a72f in terminate_due_to_signal ()
> #1  0x000303e90000faf0 in ?? ()
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)

How many threads are in the process?  Did you type "bt" when the Lisp
thread was the current one?

> Couldn't fetch xbacktrace either:
> 
> (gdb) source .gdbinit
> SIGINT is used by the debugger.
> Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
> DISPLAY = :0.0
> TERM = xterm
> Breakpoint 1 at 0x10054a66a
> .gdbinit:1228: Error in sourced command file:
> No symbol "defined_HAVE_X_WINDOWS" in current context.

Did you build Emacs with -g3 switch to GCC?

Message #11 received at 35204 <at> debbugs.gnu.org (full text, mbox):

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 35204 <at> debbugs.gnu.org
Subject: Re: bug#35204: 27.0.50; Crash on Cygwin
Date: Wed, 10 Apr 2019 13:54:16 +0900

[Message part 1 (text/plain, inline)]

On Tue, 09 Apr 2019 12:47:52 +0300, Eli Zaretskii wrote:
>> Date: Tue, 09 Apr 2019 17:07:58 +0900
>> From: Katsumi Yamaoka <yamaoka <at> jpl.org>

>> Here is a gdb backtrace I got after reverting only 1.:

>> (gdb) bt
>> #0  0x000000010054a66a in terminate_due_to_signal ()
[...]

> Is this when you run Emacs from GDB to begin with?  If not, please run
> Emacs from GDB, then the backtrace should be more informative.

I did so.  I rebuilt separately Emacs from scratch from today's
Git repo with no modification on the source using these configure
options

configure --verbose --with-x-toolkit=gtk3

(I detached "CFLAGS=-O0"), run it from gdb, and I got the
backtrace that is in the bottom of the attached GDB log.  It
might be too short to analyze, though.

>> I couldn't fetch a backtrace for Emacs before reverting because
>> of an error:

>> (gdb) bt
>> #0  0x000000010054a72f in terminate_due_to_signal ()
>> #1  0x000303e90000faf0 in ?? ()
>> Backtrace stopped: previous frame inner to this frame (corrupt stack?)

> How many threads are in the process?  Did you type "bt" when the Lisp
> thread was the current one?

There are 121 threads (IIUC).  I don't konw what is the Lisp
thread, sorry.

>> Couldn't fetch xbacktrace either:

>> (gdb) source .gdbinit
[...]
>> .gdbinit:1228: Error in sourced command file:
>> No symbol "defined_HAVE_X_WINDOWS" in current context.

> Did you build Emacs with -g3 switch to GCC?

No, I don't specify -g3 expressly/intendedly.  But it came not
to issue an error today for an unknown reason.

(I don't know why but today's Emacs lived for over an hour, so
 I was excited over a false hope.  The main Emacs that I rebuilt
 from Git master today is working fine with reverting the three
 changes in question.)

Here is the GDB log.  Thanks.

[Message part 2 (application/octet-stream, inline)]

Message #14 received at 35204 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Katsumi Yamaoka <yamaoka <at> jpl.org>
Cc: 35204 <at> debbugs.gnu.org
Subject: Re: bug#35204: 27.0.50; Crash on Cygwin
Date: Wed, 10 Apr 2019 17:37:58 +0300

> Date: Wed, 10 Apr 2019 13:54:16 +0900
> From: Katsumi Yamaoka <yamaoka <at> jpl.org>
> Cc: 35204 <at> debbugs.gnu.org
> 
> > Is this when you run Emacs from GDB to begin with?  If not, please run
> > Emacs from GDB, then the backtrace should be more informative.
> 
> I did so.  I rebuilt separately Emacs from scratch from today's
> Git repo with no modification on the source using these configure
> options
> 
> configure --verbose --with-x-toolkit=gtk3
> 
> (I detached "CFLAGS=-O0")

Does it mean you used "CFLAGS=-O0", or does it mean you did NOT use
it?  It is better to use it, together with -g3, as that makes
debugging easier.

> run it from gdb, and I got the backtrace that is in the bottom of
> the attached GDB log.  It might be too short to analyze, though.

Yes, it's still not informative enough.

> > How many threads are in the process?  Did you type "bt" when the Lisp
> > thread was the current one?
> 
> There are 121 threads (IIUC).

Is it normal to have so many threads?  What are they doing?

> I don't konw what is the Lisp thread, sorry.

That's usually the thread you get when you type "thread 1" at GDB
prompt.  But let's see what all those threads do, so please type this:

  (gdb) thread apply all bt

and post the results here.

> Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=11, 
>     backtrace_limit=40) at emacs.c:370
> 370	{
> (gdb) bt
> #0  terminate_due_to_signal (sig=11, backtrace_limit=40) at emacs.c:370
> #1  0x00000001004f134e in handle_fatal_signal (sig=sig <at> entry=11)
>     at sysdep.c:1793
> #2  0x00000001004f153f in deliver_thread_signal (sig=sig <at> entry=11, 
>     handler=0x1004f1340 <handle_fatal_signal>) at sysdep.c:1767
> #3  0x00000001004f159f in deliver_fatal_thread_signal (sig=11) at sysdep.c:1805
> #4  handle_sigsegv (sig=11, siginfo=0x1009dea10 <sigsegv_stack+32464>, 
>     arg=<optimized out>) at sysdep.c:1890
> #5  0x000000018005f65a in altstack_wrapper (sig=<optimized out>, 
>     siginfo=<optimized out>, sigctx=0xffffde50, 
>     handler=0x1004f1580 <handle_sigsegv>)
>     at /usr/src/debug/cygwin-3.0.6-1/winsup/cygwin/exceptions.cc:1595
> #6  0x0000000180062dfa in _cygtls::call_signal_handler (this=0xffffce00)
>     at /usr/src/debug/cygwin-3.0.6-1/winsup/cygwin/exceptions.cc:1777
> #7  0x0000000000000000 in ?? ()
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)

I don't think this is the thread we are interested in.  Let's see what
"thread apply all bt" shows us.

> Lisp Backtrace:
> "x-show-tip" (0xffffac20)
> "tooltip-show" (0xffffaf60)
> "tooltip-help-tips" (0xffffb2c8)
> "run-hook-with-args-until-success" (0xffffb2c0)
> "tooltip-timeout" (0xffffb670)
> "apply" (0xffffb668)
> "timer-event-handler" (0xffffb9a8)
> (gdb) 

This seems to be related to showing a tooltip.  Do the crashes
generally happen when Emacs is supposed to display a tooltip?

Also, you say that the 3 commits you identified cause the problem, but
those commits are related to the function
x-display-monitor-attributes-list.  Is this function being called in
your usage pattern?  Can you put a breakpoint inside that function and
see if it breaks, and how often?

Thanks.

Message #17 received at 35204 <at> debbugs.gnu.org (full text, mbox):

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 35204 <at> debbugs.gnu.org
Subject: Re: bug#35204: 27.0.50; Crash on Cygwin
Date: Thu, 11 Apr 2019 11:31:11 +0900

[Message part 1 (text/plain, inline)]

On Wed, 10 Apr 2019 17:37:58 +0300, Eli Zaretskii wrote:
>> I did so.  I rebuilt separately Emacs from scratch from today's
>> Git repo with no modification on the source using these configure
>> options

>> configure --verbose --with-x-toolkit=gtk3

>> (I detached "CFLAGS=-O0")

> Does it mean you used "CFLAGS=-O0", or does it mean you did NOT use
> it?  It is better to use it, together with -g3, as that makes
> debugging easier.

At that time I didn't use CFLAGS=-O0 so as to exclude anything
special, though I'm not sure it is worthwhile.  Today I tried
building two types; one uses CFLAGS=-O0 and the other doesn't.
The difference between them is that with the one built *with*
CFLAGS=-O0 the gdb command `source .gdbinit' ends up with this
error:

(gdb) source .gdbinit
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
DISPLAY = :0.0
TERM = xterm
Breakpoint 1 at 0x10054a66a
.gdbinit:1228: Error in sourced command file:
No symbol "defined_HAVE_X_WINDOWS" in current context.

[...]

>> There are 121 threads (IIUC).

> Is it normal to have so many threads?  What are they doing?

It's a result of I did many things to break Emacs since it can't
seem to die soon.  But I got a good means to break Emacs at once,
that is to eval: (x-display-monitor-attributes-list)

>> I don't konw what is the Lisp thread, sorry.

> That's usually the thread you get when you type "thread 1" at GDB
> prompt.  But let's see what all those threads do, so please type this:

>   (gdb) thread apply all bt

> and post the results here.

Thanks.  Attached the one fetched with Emacs built without
CFLAGS=-O0 (it has no notably difference from the one fetched
with Emacs built with CFLAGS=-O0).  Note that gdb crashes when
the `thread apply all bt' command is invoked.

[...]

> Also, you say that the 3 commits you identified cause the problem, but
> those commits are related to the function
> x-display-monitor-attributes-list.  Is this function being called in
> your usage pattern?  Can you put a breakpoint inside that function and
> see if it breaks, and how often?

I think I use intendedly neither such a raw function nor functions
using it.  Moreover the crash happens not when manipurating a frame.
So, the attached GDB log might not mention to the one I'm troubled
with.

Regards,

[Message part 2 (application/octet-stream, inline)]

Message #20 received at 35204 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Katsumi Yamaoka <yamaoka <at> jpl.org>
Cc: 35204 <at> debbugs.gnu.org
Subject: Re: bug#35204: 27.0.50; Crash on Cygwin
Date: Thu, 11 Apr 2019 16:19:28 +0300

> Date: Thu, 11 Apr 2019 11:31:11 +0900
> From: Katsumi Yamaoka <yamaoka <at> jpl.org>
> Cc: 35204 <at> debbugs.gnu.org
> 
> >> configure --verbose --with-x-toolkit=gtk3
> 
> >> (I detached "CFLAGS=-O0")
> 
> > Does it mean you used "CFLAGS=-O0", or does it mean you did NOT use
> > it?  It is better to use it, together with -g3, as that makes
> > debugging easier.
> 
> At that time I didn't use CFLAGS=-O0 so as to exclude anything
> special, though I'm not sure it is worthwhile.  Today I tried
> building two types; one uses CFLAGS=-O0 and the other doesn't.
> The difference between them is that with the one built *with*
> CFLAGS=-O0 the gdb command `source .gdbinit' ends up with this
> error:
> 
> (gdb) source .gdbinit
> SIGINT is used by the debugger.
> Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
> DISPLAY = :0.0
> TERM = xterm
> Breakpoint 1 at 0x10054a66a
> .gdbinit:1228: Error in sourced command file:
> No symbol "defined_HAVE_X_WINDOWS" in current context.

This is why I suggested to use CFLAGS='-O0 -g3', please try that next.

> > Is it normal to have so many threads?  What are they doing?
> 
> It's a result of I did many things to break Emacs since it can't
> seem to die soon.  But I got a good means to break Emacs at once,
> that is to eval: (x-display-monitor-attributes-list)

So please use this method from now on, to trigger the crash.  It is
important to have consistency in this.

> >> I don't konw what is the Lisp thread, sorry.
> 
> > That's usually the thread you get when you type "thread 1" at GDB
> > prompt.  But let's see what all those threads do, so please type this:
> 
> >   (gdb) thread apply all bt
> 
> > and post the results here.
> 
> Thanks.  Attached the one fetched with Emacs built without
> CFLAGS=-O0 (it has no notably difference from the one fetched
> with Emacs built with CFLAGS=-O0).  Note that gdb crashes when
> the `thread apply all bt' command is invoked.

This is still not the information we need.  Since "thread apply all"
crashes, please try this alternative:

  (gdb) thread 1
  (gdb) bt

And please separately do also this:

  (gdb) info threads

and post the results.

Thanks.

P.S. I see you are using Cygwin 3.0.6, could it be a bug in Cygwin
itself?  Is there a newer version of Cygwin?

Message #23 received at 35204 <at> debbugs.gnu.org (full text, mbox):

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 35204 <at> debbugs.gnu.org
Subject: Re: bug#35204: 27.0.50; Crash on Cygwin
Date: Fri, 12 Apr 2019 08:02:33 +0900

[Message part 1 (text/plain, inline)]

On Thu, 11 Apr 2019 16:19:28 +0300, Eli Zaretskii wrote:
>> (gdb) source .gdbinit
[...]
>> .gdbinit:1228: Error in sourced command file:
>> No symbol "defined_HAVE_X_WINDOWS" in current context.

> This is why I suggested to use CFLAGS='-O0 -g3', please try that next.

I did so.

[...]
> This is still not the information we need.  Since "thread apply all"
> crashes, please try this alternative:

>   (gdb) thread 1
>   (gdb) bt

The result is in the first attachment, and

> And please separately do also this:

>   (gdb) info threads

that of it is in the second attachment.

> and post the results.

> P.S. I see you are using Cygwin 3.0.6, could it be a bug in Cygwin
> itself?  Is there a newer version of Cygwin?

No one mentions Emacs of git master in the Cygwin list so far.
I tried to update my Cygwin installation, but setup.exe said
it is up-to-date.  So, I'll try the snapshot later.

Thanks.

[Message part 2 (application/octet-stream, inline)]

[Message part 3 (application/octet-stream, inline)]

Message #26 received at 35204 <at> debbugs.gnu.org (full text, mbox):

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 35204 <at> debbugs.gnu.org
Subject: Re: bug#35204: 27.0.50; Crash on Cygwin
Date: Fri, 12 Apr 2019 10:01:57 +0900

On Fri, 12 Apr 2019 08:02:33 +0900, Katsumi Yamaoka wrote:
>> P.S. I see you are using Cygwin 3.0.6, could it be a bug in Cygwin
>> itself?  Is there a newer version of Cygwin?

> No one mentions Emacs of git master in the Cygwin list so far.
> I tried to update my Cygwin installation, but setup.exe said
> it is up-to-date.  So, I'll try the snapshot later.

Nothing seems to change with Emacs rebuilt on:

uname -a
CYGWIN_NT-10.0 localhost 3.1.0s(0.338/5/3) 2019-04-10 20:49 x86_64 Cygwin

Regards,

Message #29 received at 35204 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Katsumi Yamaoka <yamaoka <at> jpl.org>, Ken Brown <kbrown <at> cornell.edu>
Cc: 35204 <at> debbugs.gnu.org
Subject: Re: bug#35204: 27.0.50; Crash on Cygwin
Date: Fri, 12 Apr 2019 10:11:12 +0300

> Date: Fri, 12 Apr 2019 08:02:33 +0900
> From: Katsumi Yamaoka <yamaoka <at> jpl.org>
> Cc: 35204 <at> debbugs.gnu.org
> 
> >   (gdb) thread 1
> >   (gdb) bt
> 
> The result is in the first attachment, and
> 
> > And please separately do also this:
> 
> >   (gdb) info threads
> 
> that of it is in the second attachment.
> 
> > and post the results.

It's strange.  Looks like there's a bug in your GDB, because it dumps
core in this case.  I also don't understand why the backtrace ends in
the exception handler, it sounds like GDB is not given the first
opportunity to handle an exception, as it should?  Maybe try upgrading
to GDB 8.2, if its Cygwin port is available?

Ken, could you please chime in?  It is strange that this problem only
affects the Cygwin build, and no other bug report points to that
change from other GTK builds, including not from other Cygwin users.
So it sounds like a Cygwin problem, perhaps triggered by something on
Yamaoka-san's machine, but the fact that GDB crashes doesn't allow any
reasonable way of investigating the problem past the exception
handler.  I don't know what to do next.

Message #32 received at 35204 <at> debbugs.gnu.org (full text, mbox):

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 35204 <at> debbugs.gnu.org, Ken Brown <kbrown <at> cornell.edu>
Subject: Re: bug#35204: 27.0.50; Crash on Cygwin
Date: Fri, 12 Apr 2019 17:00:52 +0900

On Fri, 12 Apr 2019 10:11:12 +0300, Eli Zaretskii wrote:
> Maybe try upgrading to GDB 8.2, if its Cygwin port is available?

I'm now trying building GDB 8.2.1 from scratch but time to
depart from the office where I have Cygwin installed has come
(the configure process is still running as if it is endless).
So, I'll try it again next week.  Thanks anyway.

Message #35 received at 35204 <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>, Katsumi Yamaoka <yamaoka <at> jpl.org>
Cc: "35204 <at> debbugs.gnu.org" <35204 <at> debbugs.gnu.org>
Subject: Re: bug#35204: 27.0.50; Crash on Cygwin
Date: Fri, 12 Apr 2019 14:54:21 +0000

On 4/12/2019 3:11 AM, Eli Zaretskii wrote:
> Ken, could you please chime in?  It is strange that this problem only
> affects the Cygwin build, and no other bug report points to that
> change from other GTK builds

Sorry for not chiming in sooner.  I saw the bug report but was busy with other 
things.

I can replicate the crash on my system, but reverting only a tiny part of the 
commits in question seems to fix it, in the sense that I can successfully 
evaluate x-display-monitor-attributes-list:

diff --git a/src/xfns.c b/src/xfns.c
index 13f66f0718..3e4d037716 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -5030,7 +5030,7 @@ Internal use only, use `display-monitor-attributes-list' 
instead.  */)
        mi->mm_height = height_mm;

  #if GTK_CHECK_VERSION (3, 22, 0)
-      mi->name = xstrdup (gdk_monitor_get_model (monitor));
+      mi->name = g_strdup (gdk_monitor_get_model (monitor));
  #elif GTK_CHECK_VERSION (2, 14, 0)
        mi->name = gdk_screen_get_monitor_plug_name (gscreen, i);
  #endif

I don't know enough about GTK to know why this fixes it or why no one else has 
reported the problem.  It's hard to see why this would be specific to Cygwin.

Ken

Message #38 received at 35204 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: yamaoka <at> jpl.org, 35204 <at> debbugs.gnu.org
Subject: Re: bug#35204: 27.0.50; Crash on Cygwin
Date: Fri, 12 Apr 2019 18:15:40 +0300

> From: Ken Brown <kbrown <at> cornell.edu>
> CC: "35204 <at> debbugs.gnu.org" <35204 <at> debbugs.gnu.org>
> Date: Fri, 12 Apr 2019 14:54:21 +0000
> 
> I can replicate the crash on my system, but reverting only a tiny part of the 
> commits in question seems to fix it, in the sense that I can successfully 
> evaluate x-display-monitor-attributes-list:
> 
> diff --git a/src/xfns.c b/src/xfns.c
> index 13f66f0718..3e4d037716 100644
> --- a/src/xfns.c
> +++ b/src/xfns.c
> @@ -5030,7 +5030,7 @@ Internal use only, use `display-monitor-attributes-list' 
> instead.  */)
>         mi->mm_height = height_mm;
> 
>   #if GTK_CHECK_VERSION (3, 22, 0)
> -      mi->name = xstrdup (gdk_monitor_get_model (monitor));
> +      mi->name = g_strdup (gdk_monitor_get_model (monitor));
>   #elif GTK_CHECK_VERSION (2, 14, 0)
>         mi->name = gdk_screen_get_monitor_plug_name (gscreen, i);
>   #endif
> 
> I don't know enough about GTK to know why this fixes it or why no one else has 
> reported the problem.  It's hard to see why this would be specific to Cygwin.

We release storage of mi->name (in free_monitors) by calling xfree, so
I'm surprised g_strdup is right here, as that is documented to need
g_free instead.  I wonder what am I missing.

Message #41 received at 35204 <at> debbugs.gnu.org (full text, mbox):

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: yamaoka <at> jpl.org, 35204 <at> debbugs.gnu.org, Ken Brown <kbrown <at> cornell.edu>
Subject: Re: bug#35204: 27.0.50; Crash on Cygwin
Date: Sat, 13 Apr 2019 23:26:13 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Ken Brown <kbrown <at> cornell.edu>
>> CC: "35204 <at> debbugs.gnu.org" <35204 <at> debbugs.gnu.org>
>> Date: Fri, 12 Apr 2019 14:54:21 +0000
>> 
>> I can replicate the crash on my system, but reverting only a tiny part of the 
>> commits in question seems to fix it, in the sense that I can successfully 
>> evaluate x-display-monitor-attributes-list:
>> 
>> diff --git a/src/xfns.c b/src/xfns.c
>> index 13f66f0718..3e4d037716 100644
>> --- a/src/xfns.c
>> +++ b/src/xfns.c
>> @@ -5030,7 +5030,7 @@ Internal use only, use `display-monitor-attributes-list' 
>> instead.  */)
>>         mi->mm_height = height_mm;
>> 
>>   #if GTK_CHECK_VERSION (3, 22, 0)
>> -      mi->name = xstrdup (gdk_monitor_get_model (monitor));
>> +      mi->name = g_strdup (gdk_monitor_get_model (monitor));
>>   #elif GTK_CHECK_VERSION (2, 14, 0)
>>         mi->name = gdk_screen_get_monitor_plug_name (gscreen, i);
>>   #endif
>> 
>> I don't know enough about GTK to know why this fixes it or why no one else has 
>> reported the problem.  It's hard to see why this would be specific to Cygwin.
>
> We release storage of mi->name (in free_monitors) by calling xfree, so
> I'm surprised g_strdup is right here, as that is documented to need
> g_free instead.  I wonder what am I missing.

I think the missing clue is in bug#35259: gdk_monitor_get_model may
return NULL, which g_strdup gladly accepts, but xstrdup does not.

https://debbugs.gnu.org/35259

-- 
Basil

Message #44 received at 35204 <at> debbugs.gnu.org (full text, mbox):

From: Alex Gramiak <agrambot <at> gmail.com>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: Eli Zaretskii <eliz <at> gnu.org>, yamaoka <at> jpl.org, 35204 <at> debbugs.gnu.org
Subject: Re: bug#35204: 27.0.50; Crash on Cygwin
Date: Sat, 13 Apr 2019 16:50:38 -0600

"Basil L. Contovounesios" <contovob <at> tcd.ie> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Ken Brown <kbrown <at> cornell.edu>
>>> CC: "35204 <at> debbugs.gnu.org" <35204 <at> debbugs.gnu.org>
>>> Date: Fri, 12 Apr 2019 14:54:21 +0000
>>> 
>>> I can replicate the crash on my system, but reverting only a tiny part of the 
>>> commits in question seems to fix it, in the sense that I can successfully 
>>> evaluate x-display-monitor-attributes-list:
>>> 
>>> diff --git a/src/xfns.c b/src/xfns.c
>>> index 13f66f0718..3e4d037716 100644
>>> --- a/src/xfns.c
>>> +++ b/src/xfns.c
>>> @@ -5030,7 +5030,7 @@ Internal use only, use `display-monitor-attributes-list' 
>>> instead.  */)
>>>         mi->mm_height = height_mm;
>>> 
>>>   #if GTK_CHECK_VERSION (3, 22, 0)
>>> -      mi->name = xstrdup (gdk_monitor_get_model (monitor));
>>> +      mi->name = g_strdup (gdk_monitor_get_model (monitor));
>>>   #elif GTK_CHECK_VERSION (2, 14, 0)
>>>         mi->name = gdk_screen_get_monitor_plug_name (gscreen, i);
>>>   #endif
>>> 
>>> I don't know enough about GTK to know why this fixes it or why no one else has 
>>> reported the problem.  It's hard to see why this would be specific to Cygwin.
>>
>> We release storage of mi->name (in free_monitors) by calling xfree, so
>> I'm surprised g_strdup is right here, as that is documented to need
>> g_free instead.  I wonder what am I missing.
>
> I think the missing clue is in bug#35259: gdk_monitor_get_model may
> return NULL, which g_strdup gladly accepts, but xstrdup does not.
>
> https://debbugs.gnu.org/35259

Yeah, this is it. I suppose the reason why it wasn't reported before is
that it depends on GTK not being able to grab your monitor name, which
is hardware-dependent. I must have assumed that using g_strdup meant
that I didn't need to check for NULL.

It should be fixed with commit 7308c2edf, so please test again. Sorry
for the inconvenience.

Message #47 received at 35204 <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Alex Gramiak <agrambot <at> gmail.com>, "Basil L. Contovounesios"
 <contovob <at> tcd.ie>
Cc: "yamaoka <at> jpl.org" <yamaoka <at> jpl.org>,
 "35204 <at> debbugs.gnu.org" <35204 <at> debbugs.gnu.org>
Subject: Re: bug#35204: 27.0.50; Crash on Cygwin
Date: Sun, 14 Apr 2019 02:15:00 +0000

On 4/13/2019 6:50 PM, Alex Gramiak wrote:
> "Basil L. Contovounesios" <contovob <at> tcd.ie> writes:
>> I think the missing clue is in bug#35259: gdk_monitor_get_model may
>> return NULL, which g_strdup gladly accepts, but xstrdup does not.
>>
>> https://debbugs.gnu.org/35259
> 
> Yeah, this is it. I suppose the reason why it wasn't reported before is
> that it depends on GTK not being able to grab your monitor name, which
> is hardware-dependent. I must have assumed that using g_strdup meant
> that I didn't need to check for NULL.
> 
> It should be fixed with commit 7308c2edf, so please test again. Sorry
> for the inconvenience.

Yes, that fixes it for me.

Thanks.

Ken

Message #52 received at 35204-done <at> debbugs.gnu.org (full text, mbox):

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: Alex Gramiak <agrambot <at> gmail.com>
Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, Ken Brown <kbrown <at> cornell.edu>,
 35204-done <at> debbugs.gnu.org
Subject: Re: bug#35204: 27.0.50; Crash on Cygwin
Date: Mon, 15 Apr 2019 08:26:15 +0900

On Sun, 14 Apr 2019 02:15:00 +0000, Ken Brown wrote:
>> It should be fixed with commit 7308c2edf, so please test again. Sorry
>> for the inconvenience.

> Yes, that fixes it for me.

Emacs built from the fresh git master works fine.  Thanks a lot!

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.