X-Recipient:	archive-cygwin AT delorie DOT com
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=bqnqzb/+YNLSoMj0
	pziSthzZDdsPjSEhO/yBhgZjF5jiuNoowJjpI97lTCKWrcdL5OZmxsqmy+3wbEOZ
	o3y0zncRed3ZPPm3uD5TwreBHaJvi1N3Zg8eLdqgTVGjFV50SGy5qgy+OgJOAsA5
	+kr3Ve38Pz2LJz50P2RNzys/fn8=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; 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; s=default; bh=TpItLIlkRPYOMzIKdmEK4g
	3m5lE=; b=qRfs5Zv/yj8K87u9FP2wj1NL4VYsM/62cZcDt96NXX9SdHLWgh9tMx
	zn/Ac4EIvGN5FZNZYTaZ3iYheMBJSGeo5DGR8g/QYfTQTtr4phiDcUW6DwWJEMUL
	Zfw9s9iHPQ8eZUaFWqh4GqHd9ACLIY1yfe4yxByujVzd228n7LIXU=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-HELO:	limerock02.mail.cornell.edu
X-CornellRouted:	This message has been Routed already.
Message-ID:	<53AB8302.3070804@cornell.edu>
Date:	Wed, 25 Jun 2014 22:18:42 -0400
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> <53A444C2 DOT 3020903 AT cornell DOT edu> <83simzr6s3 DOT fsf AT gnu DOT org>
In-Reply-To:	<83simzr6s3.fsf@gnu.org>
X-IsSubscribed:	yes

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

- Raw text -