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

Thu Jun 26 02:19:00 GMT 2014

On 6/20/2014 10:32 AM, Eli Zaretskii wrote:
>> Date: 2014年6月20日 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