bzr emacs(24.4.50.1) crashes when using auto-revert-tail-mode

[Ken Brown]

On 6/20/2014 10:32 AM, Eli Zaretskii wrote:
>> Date: Fri, 20 Jun 2014 15:27:14 +0100
>> From: Ken Brown
>>
>>> 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.
>
> Then I guess rebuilding Glib and pthreads with -O0 -g3 is the way to
> go.  the above looks like pthreads tried to lock a mutex for a thread
> that was not created correctly, or maybe exited right away.  But
> that's a guess, and without debug info it's hard to say something
> intelligent.

This turns out to be a Glib/Cygwin bug, having nothing to do with Emacs. 
  I've started a new thread to report this:

   https://cygwin.com/ml/cygwin/2014-06/msg00406.html

Ken

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