> 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.
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? If not, perhaps using the same versions will resolve the
problem.
> (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?
--
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
