* bzr emacs(24.4.50.1) crashes when using auto-revert-tail-mode
@ 2014-06-18 15:06 Filipp Gunbin
2014-06-18 17:47 ` Ken Brown
0 siblings, 1 reply; 8+ messages in thread
From: Filipp Gunbin @ 2014-06-18 15:06 UTC (permalink / raw)
To: cygwin
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>
M-x auto-revert-tail-mode
wait for few seconds -> emacs crashes
Filipp
--
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: bzr emacs(24.4.50.1) crashes when using auto-revert-tail-mode
2014-06-18 15:06 bzr emacs(24.4.50.1) crashes when using auto-revert-tail-mode Filipp Gunbin
@ 2014-06-18 17:47 ` Ken Brown
2014-06-19 13:11 ` Ken Brown
2014-06-19 14:53 ` Filipp Gunbin
0 siblings, 2 replies; 8+ messages in thread
From: Ken Brown @ 2014-06-18 17:47 UTC (permalink / raw)
To: cygwin
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.
Ken
P.S. Since you're building your own emacs from the bzr sources, it would
be more useful for you to test the emacs-24 branch rather than the
trunk; that's where bug fixes for emacs-24.4 are being made.
--
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: bzr emacs(24.4.50.1) crashes when using auto-revert-tail-mode
2014-06-18 17:47 ` Ken Brown
@ 2014-06-19 13:11 ` Ken Brown
2014-06-19 14:55 ` Filipp Gunbin
2014-06-20 13:05 ` Eli Zaretskii
2014-06-19 14:53 ` Filipp Gunbin
1 sibling, 2 replies; 8+ messages in thread
From: Ken Brown @ 2014-06-19 13:11 UTC (permalink / raw)
To: cygwin
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.
Filipp, do you want to try debugging this yourself? Maybe your debugging skills are better than mine. (You'll need to install glib2.0-debuginfo.)
Ken
$ gdb /usr/bin/emacs-w32.exe
GNU gdb (GDB) 7.6.50.20130728-cvs (cygwin-special)
[...]
Reading symbols from /usr/bin/emacs-w32.exe...Reading symbols from /usr/lib/debug/usr/bin/emacs-w32.exe.dbg...done.
done.
(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
--
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: bzr emacs(24.4.50.1) crashes when using auto-revert-tail-mode
2014-06-18 17:47 ` Ken Brown
2014-06-19 13:11 ` Ken Brown
@ 2014-06-19 14:53 ` Filipp Gunbin
1 sibling, 0 replies; 8+ messages in thread
From: Filipp Gunbin @ 2014-06-19 14:53 UTC (permalink / raw)
To: cygwin
Ken,
On 18/06/2014 21:46 +0400, Ken Brown wrote:
> On 6/18/2014 11:06 AM, Filipp Gunbin wrote:
>> C-x C-r <some_file>
>
> You mean C-x C-f
I did C-x C-r but that should not matter.
>
>> 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.)
>
> I'll look into this. In the meantime, you can work around it by
> configuring --with-file-notification=no.
Thanks!
> P.S. Since you're building your own emacs from the bzr sources, it
> would be more useful for you to test the emacs-24 branch rather than
> the trunk; that's where bug fixes for emacs-24.4 are being made.
Noted, thanks.
Filipp
--
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: bzr emacs(24.4.50.1) crashes when using auto-revert-tail-mode
2014-06-19 13:11 ` Ken Brown
@ 2014-06-19 14:55 ` Filipp Gunbin
2014-06-20 13:05 ` Eli Zaretskii
1 sibling, 0 replies; 8+ messages in thread
From: Filipp Gunbin @ 2014-06-19 14:55 UTC (permalink / raw)
To: cygwin
On 19/06/2014 17:11 +0400, Ken Brown wrote:
> On 6/18/2014 1:46 PM, Ken Brown wrote:
> 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.
>
> Filipp, do you want to try debugging this yourself? Maybe your
> debugging skills are better than mine. (You'll need to install
> glib2.0-debuginfo.)
Well I'll try, but I'm not a C programmer and have little experience
with gdb :(
Filipp
--
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: bzr emacs(24.4.50.1) crashes when using auto-revert-tail-mode
2014-06-19 13:11 ` Ken Brown
2014-06-19 14:55 ` Filipp Gunbin
@ 2014-06-20 13:05 ` Eli Zaretskii
2014-06-20 14:27 ` Ken Brown
1 sibling, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2014-06-20 13:05 UTC (permalink / raw)
To: Ken Brown; +Cc: cygwin
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: bzr emacs(24.4.50.1) crashes when using auto-revert-tail-mode
2014-06-20 13:05 ` Eli Zaretskii
@ 2014-06-20 14:27 ` Ken Brown
[not found] ` <83simzr6s3.fsf@gnu.org>
0 siblings, 1 reply; 8+ messages in thread
From: Ken Brown @ 2014-06-20 14:27 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: cygwin
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: bzr emacs(24.4.50.1) crashes when using auto-revert-tail-mode
[not found] ` <83simzr6s3.fsf@gnu.org>
@ 2014-06-26 2:19 ` Ken Brown
0 siblings, 0 replies; 8+ messages in thread
From: Ken Brown @ 2014-06-26 2:19 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: cygwin
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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-06-26 2:19 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-18 15:06 bzr emacs(24.4.50.1) crashes when using auto-revert-tail-mode Filipp Gunbin
2014-06-18 17:47 ` Ken Brown
2014-06-19 13:11 ` Ken Brown
2014-06-19 14:55 ` Filipp Gunbin
2014-06-20 13:05 ` Eli Zaretskii
2014-06-20 14:27 ` Ken Brown
[not found] ` <83simzr6s3.fsf@gnu.org>
2014-06-26 2:19 ` Ken Brown
2014-06-19 14:53 ` Filipp Gunbin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).