DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=Z+eUduDokvZLUEP9
	qyMY23SjYk2IsJw0aUF/uzrbFZEKZ3KHir3XU9HgZIx8DYc1uHYJeJDGYCyPr5Ho
	32DfX+v6iv5XK0VLtAmd4QQhlI6KzGV671eeJ3nOtym+8Z2o4RlA86J8Dtx9jdmu
	g3j1DpwRT/ueFGqxvH+DkBmb6IQ=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <53A444C2.3020903@cornell.edu>
Date: Fri, 20 Jun 2014 15:27:14 +0100
From: Ken Brown <kbrown AT cornell DOT edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Eli Zaretskii <eliz AT gnu DOT org>
CC: cygwin AT cygwin DOT com
Subject: Re: bzr emacs(24.4.50.1) crashes when using auto-revert-tail-mode
References: <86mwda6yv6 DOT fsf AT w2139spb DOT ru DOT yotateam DOT com> <53A1D076 DOT 8090109 AT cornell DOT edu> <53A2E189 DOT 9080203 AT cornell DOT edu> <834mzfspef DOT fsf AT gnu DOT org>
In-Reply-To: <834mzfspef.fsf@gnu.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 6/20/2014 2:04 PM, Eli Zaretskii wrote:
>> Date: Thu, 19 Jun 2014 09:11:37 -0400
>> From: Ken Brown
>>
>> On 6/18/2014 1:46 PM, Ken Brown wrote:
>>> On 6/18/2014 11:06 AM, Filipp Gunbin wrote:
>>>> I'm not sure whether this is Cygwin-specific, but I'm not able to test
>>>> it on other OS, so here are the steps to reproduce:
>>>>
>>>> emacs -Q
>>>> C-x C-r <some_file>
>>>
>>> You mean C-x C-f
>>>
>>>> M-x auto-revert-tail-mode
>>>> wait for few seconds -> emacs crashes
>>>
>>> I can confirm this, but on 32-bit Cygwin only; there's no crash on
>>> 64-bit Cygwin.  (This is a refreshing change from the emacs crashes
>>> people have been reporting on 64-bit Cygwin.)
>>>
>>> Here's the backtrace:
>>>
>>> #0  0x00000000 in ?? ()
>>> No symbol table info available.
>>> #1  0x610f842f in pthread_mutex::lock (this=0x0)
>>>       at /usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/thread.cc:1745
>>>           self = <optimized out>
>>>           result = <optimized out>
>>>           __PRETTY_FUNCTION__ = "int pthread_mutex::lock()"
>>> #2  0x00000201 in ?? ()
>>> No symbol table info available.
>>>
>>> Lisp Backtrace:
>>> "gfile-add-watch" (0x288dc8)
>>> "file-notify-add-watch" (0x2890c8)
>>> "byte-code" (0x289340)
>>> "auto-revert-notify-add-watch" (0x289778)
>>> "auto-revert-buffers" (0x289b4c)
>>> "apply" (0x289b48)
>>> "byte-code" (0x289dc0)
>>> "timer-event-handler" (0x28a1fc)
>>>
>>> I'll look into this.  In the meantime, you can work around it by
>>> configuring --with-file-notification=no.
>>
>> I'm afraid I ran into a brick wall trying to debug this.  I wanted to see what gfile-add-watch was doing, so I ran emacs under gdb with a breakpoint at Fgfile_add_watch and then a breakpoint at g_file_monitor (a Glib function called by Fgfile_add_watch).  When I tried to step through this function, I hit an assertion violation in gdb.  This is repeatable.  A log of the gdb session is appended below.
>>
>> The problem occurs only on 32-bit Cygwin.  On 64-bit Cygwin, I can step through Fgfile_add_watch without a problem.
> 
> Debugging Glib applications is not for the faint at heart.  Its
> OO-like objects intentionally conceal their innards from the outside
> world, and appear as opaque objects in the debugger, unless you
> actually step deep enough into the methods.
> 
> I generally find myself unable to debug Glib, unless I build Glib
> without optimizations and with -g3.
> 
> I'd suggest to begin with looking at this from the Emacs side.  Do I
> understand correctly that this works with previous versions of w32
> Emacs?  If someone can show which past version of Cygwin-w32 build of
> Emacs worked with gfilenotify, then looking at the differences between
> then and now might show the way.

Maybe Filipp can answer this.  I've never (knowingly) had occasion to use gfilenotify.  And even if I had used it, I almost always use 64-bit Cygwin unless I'm testing something or responding to a bug report.

> If no one can tell what past version worked, then I suggest to build
> Glib with -O0 -g3, and debug that.  From the crash traceback, it
> sounds like pthreads might also be involved, so I recommend to build
> that with -O0 -g3 as well.  Then see if the backtrace becomes more
> useful.
> 
> Also, does the 64-bit build use the same versions of Glib and
> pthreads?

Yes.

>> (gdb) b Fgfile_add_watch
>> Breakpoint 1 at 0x5f7a3f: file /usr/src/debug/emacs-24.3.91-2/src/gfilenotify.c, line 170.
>> (gdb) r -Q
>> Starting program: /usr/bin/emacs-w32.exe -Q
>> [...]
>> Breakpoint 1, Fgfile_add_watch (file=-2145740495, flags=13798510,
>>      callback=-2146880150)
>>      at /usr/src/debug/emacs-24.3.91-2/src/gfilenotify.c:170
>> 170       GFileMonitorFlags gflags = G_FILE_MONITOR_NONE;
>> (gdb) b g_file_monitor
>> Breakpoint 2 at 0x6a357e50: file /usr/src/debug/glib2.0-2.38.2-2/gio/gfile.c, line 5338.
>> (gdb) c
>> Continuing.
>> [...]
>> Breakpoint 2, g_file_monitor (file=0x80061530,
>>      flags=(G_FILE_MONITOR_WATCH_MOUNTS | G_FILE_MONITOR_SEND_MOVED),
>>      cancellable=0x0, error=0x0)
>>      at /usr/src/debug/glib2.0-2.38.2-2/gio/gfile.c:5338
>> 5338    {
>> (gdb) n
>> 5339      if (g_file_query_file_type (file, 0, cancellable) == G_FILE_TYPE_DIRECTORY)
>> (gdb) n
>> 5338    {
>> (gdb) n
>> 5339      if (g_file_query_file_type (file, 0, cancellable) == G_FILE_TYPE_DIRECTORY)
>> (gdb) n
>> 5340        return g_file_monitor_directory (file,
>> (gdb) n
>> 5339      if (g_file_query_file_type (file, 0, cancellable) == G_FILE_TYPE_DIRECTORY)
>> (gdb) n
>> 5341                                         flags & ~G_FILE_MONITOR_WATCH_HARD_LINKS,
>> (gdb) n
>> 5340        return g_file_monitor_directory (file,
>> (gdb) n
>> 5345    }
>> (gdb) n
>> 5340        return g_file_monitor_directory (file,
>> (gdb) n
>> g_file_monitor_directory (file=0x80061530,
>>      flags=(G_FILE_MONITOR_WATCH_MOUNTS | G_FILE_MONITOR_SEND_MOVED),
>>      cancellable=0x0, error=0x0)
>>      at /usr/src/debug/glib2.0-2.38.2-2/gio/gfile.c:5235
>> 5235    {
>> (gdb) n
>> 5238      g_return_val_if_fail (G_IS_FILE (file), NULL);
>> (gdb) n
>> /netrel/src/gdb-7.6.50-4/gdb/infrun.c:1942: internal-error: resume: Assertion `pc_in_thread_step_range (pc, tp)' failed.
>> A problem internal to GDB has been detected,
>> further debugging may prove unreliable.
>> Quit this debugging session? (y or n) y
> 
> Why did you need to step through the Glib code?  AFAIU, the file
> monitor did trigger, so what I would first look at is the data it
> delivers back to Emacs, not how the monitor works internally.  Did you
> try that?

Yes, that's what I tried first.  I get a SEGV right after the call to g_file_monitor:

(gdb) b Fgfile_add_watch
Breakpoint 3 at 0x5f7a3f: file /usr/src/debug/emacs-24.3.91-2/src/gfilenotify.c, line 170.
(gdb) r -Q
[...]
Breakpoint 3, Fgfile_add_watch (file=-2146927663, flags=12352654,
    callback=-2145717982)
    at /usr/src/debug/emacs-24.3.91-2/src/gfilenotify.c:170
170       GFileMonitorFlags gflags = G_FILE_MONITOR_NONE;
(gdb) n
173       CHECK_STRING (file);
(gdb) n
174       file = Fdirectory_file_name (Fexpand_file_name (file, Qnil));
(gdb) n
175       if (NILP (Ffile_exists_p (file)))
(gdb) n
178       CHECK_LIST (flags);
(gdb) n
180       if (!FUNCTIONP (callback))
(gdb) n
184       gfile = g_file_new_for_path (SSDATA (ENCODE_FILE (file)));
(gdb) n
[New Thread 6112.0x974]
[New Thread 6112.0x4c4]
187       if (!NILP (Fmember (Qwatch_mounts, flags)))
(gdb) n
188         gflags |= G_FILE_MONITOR_WATCH_MOUNTS;
(gdb) n
189       if (!NILP (Fmember (Qsend_moved, flags)))
(gdb) n
190         gflags |= G_FILE_MONITOR_SEND_MOVED;
(gdb) n
193       monitor = g_file_monitor (gfile, gflags, NULL, NULL);
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt full
#0  0x00000000 in ?? ()
No symbol table info available.
#1  0x610f842f in pthread_mutex::lock (this=0x0)
    at /usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/thread.cc:1745
        self = <optimized out>
        result = <optimized out>
        __PRETTY_FUNCTION__ = "int pthread_mutex::lock()"
#2  0x00000201 in ?? ()
No symbol table info available.

Lisp Backtrace:
"gfile-add-watch" (0x288d48)
"file-notify-add-watch" (0x289048)
"byte-code" (0x2892c0)
"auto-revert-notify-add-watch" (0x2896f8)
"auto-revert-buffers" (0x289acc)
"apply" (0x289ac8)
"byte-code" (0x289d40)
"timer-event-handler" (0x28a17c)


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple