bug#15893: 24.3.50; emacs_backtrace

bug#15893: 24.3.50; emacs_backtrace

[Dani Moncayo]

??
??:0
??
??:0
w32_backtrace at w32fns.c:7958
emacs_abort at w32fns.c:7990
terminate_due_to_signal at emacs.c:377
die at alloc.c:6737
set_cache_region at region-cache.c:363
revalidate_region_cache at region-cache.c:588
invalidate_region_cache at region-cache.c:477
prepare_to_modify_buffer at insdel.c:1874
insert_from_buffer_1 at insdel.c:1096
insert_from_buffer at insdel.c:1043
Finsert_file_contents at fileio.c:4044
Ffuncall at eval.c:2821
exec_byte_code at bytecode.c:919
funcall_lambda at eval.c:2973
Ffuncall at eval.c:2854
exec_byte_code at bytecode.c:919
funcall_lambda at eval.c:2973
Ffuncall at eval.c:2854
exec_byte_code at bytecode.c:919
funcall_lambda at eval.c:2973
Ffuncall at eval.c:2854
exec_byte_code at bytecode.c:919
funcall_lambda at eval.c:3039
Ffuncall at eval.c:2854
call1 at eval.c:2604
lock_file at filelock.c:709
prepare_to_modify_buffer_1 at insdel.c:1836
prepare_to_modify_buffer at insdel.c:1871
insert_1_both at insdel.c:797
insert_and_inherit at insdel.c:593
internal_self_insert at cmds.c:489
Fself_insert_command at cmds.c:310
Ffuncall at eval.c:2805
Fcall_interactively at callint.c:836
Ffuncall at eval.c:2812
exec_byte_code at bytecode.c:919
funcall_lambda at eval.c:2973
Ffuncall at eval.c:2854
call1 at eval.c:2604
command_loop_1 at keyboard.c:1551
internal_condition_case at eval.c:1344
command_loop_2 at keyboard.c:1169
internal_catch at eval.c:1108
command_loop at keyboard.c:1148
recursive_edit_1 at keyboard.c:776
Frecursive_edit at keyboard.c:840
main at emacs.c:1594
__mingw_CRTStartup at crt1.c:244
mainCRTStartup at crt1.c:264
_start at unexw32.c:117
??
??:0


In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-11-12 on LEG570
Windowing system distributor `Microsoft Corp.', version 5.2.3790
Configured using:
 `configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'

Important settings:
  value of $LANG: ESP
  locale-coding-system: cp1252
  default enable-multibyte-characters: t


-- 
Dani Moncayo

bug#15893: 24.3.50; emacs_backtrace

[Eli Zaretskii]

merge 15893 15841
thanks

> Date: Thu, 14 Nov 2013 14:27:36 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> 
> w32_backtrace at w32fns.c:7958
> emacs_abort at w32fns.c:7990
> terminate_due_to_signal at emacs.c:377
> die at alloc.c:6737
> set_cache_region at region-cache.c:363
> revalidate_region_cache at region-cache.c:588
> invalidate_region_cache at region-cache.c:477
> prepare_to_modify_buffer at insdel.c:1874
> insert_from_buffer_1 at insdel.c:1096
> insert_from_buffer at insdel.c:1043
> Finsert_file_contents at fileio.c:4044

This is a duplicate of 15841.

If you can recall what were you doing when this happened, please tell.

bug#15893: 24.3.50; emacs_backtrace

[Dani Moncayo]

> If you can recall what were you doing when this happened, please tell.

Reverting a buffer which was updated by another program.

-- 
Dani Moncayo

bug#15893: 24.3.50; emacs_backtrace

[Dani Moncayo]

>> If you can recall what were you doing when this happened, please tell.
>
> Reverting a buffer which was updated by another program.
                     ^^^^^
            replace with "whose file"

-- 
Dani Moncayo

bug#15893: 24.3.50; emacs_backtrace

[Eli Zaretskii]

> Date: Thu, 14 Nov 2013 17:46:52 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 15893@debbugs.gnu.org, control@debbugs.gnu.org
> 
> > If you can recall what were you doing when this happened, please tell.
> 
> Reverting a buffer which was updated by another program.

Thanks.

bug#15893: 24.3.50; emacs_backtrace

[Dani Moncayo]

>> > If you can recall what were you doing when this happened, please tell.
>>
>> Reverting a buffer which was updated by another program.
>
> Thanks.

FWIW: Today (with an Emacs build yesterday from trunk) I've got two
more crashes while reverting buffers.

Here is the backtrace:

??
??:0
??
??:0
w32_backtrace at w32fns.c:7958
emacs_abort at w32fns.c:7990
terminate_due_to_signal at emacs.c:377
die at alloc.c:6726
buf_charpos_to_bytepos at marker.c:145
find_newline at search.c:701
Fforward_line at cmds.c:138
Fline_beginning_position at editfns.c:772
Ffuncall at eval.c:2805
exec_byte_code at bytecode.c:919
funcall_lambda at eval.c:3039
Ffuncall at eval.c:2854
funcall_nil at eval.c:2356
run_hook_with_args at eval.c:2541
Frun_hook_with_args at eval.c:2402
Ffuncall at eval.c:2786
exec_byte_code at bytecode.c:919
funcall_lambda at eval.c:2973
Ffuncall at eval.c:2854
funcall_nil at eval.c:2356
run_hook_with_args at eval.c:2541
Frun_hook_with_args at eval.c:2402
signal_after_change at insdel.c:2081
del_range_byte at insdel.c:1637
Finsert_file_contents at fileio.c:4019
Ffuncall at eval.c:2821
exec_byte_code at bytecode.c:919
funcall_lambda at eval.c:2973
Ffuncall at eval.c:2854
exec_byte_code at bytecode.c:919
funcall_lambda at eval.c:2973
Ffuncall at eval.c:2854
exec_byte_code at bytecode.c:919
funcall_lambda at eval.c:2973
Ffuncall at eval.c:2854
exec_byte_code at bytecode.c:919
funcall_lambda at eval.c:3039
Ffuncall at eval.c:2854
call1 at eval.c:2604
lock_file at filelock.c:709
prepare_to_modify_buffer_1 at insdel.c:1841
prepare_to_modify_buffer at insdel.c:1876
insert_1_both at insdel.c:797
insert_and_inherit at insdel.c:593
internal_self_insert at cmds.c:489
Fself_insert_command at cmds.c:310
Ffuncall at eval.c:2805
Fcall_interactively at callint.c:836
Ffuncall at eval.c:2812
exec_byte_code at bytecode.c:919
funcall_lambda at eval.c:2973
Ffuncall at eval.c:2854
call1 at eval.c:2604
command_loop_1 at keyboard.c:1551
internal_condition_case at eval.c:1344
command_loop_2 at keyboard.c:1169
internal_catch at eval.c:1108
command_loop at keyboard.c:1148
recursive_edit_1 at keyboard.c:776
Frecursive_edit at keyboard.c:840
main at emacs.c:1594
__mingw_CRTStartup at crt1.c:244
??
??:0

-- 
Dani Moncayo

bug#15893: 24.3.50; emacs_backtrace

[Eli Zaretskii]

> Date: Tue, 26 Nov 2013 14:57:52 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> 
> >> > If you can recall what were you doing when this happened, please tell.
> >>
> >> Reverting a buffer which was updated by another program.
> >
> > Thanks.
> 
> FWIW: Today (with an Emacs build yesterday from trunk) I've got two
> more crashes while reverting buffers.

Thanks.  However, without a recipe to reproduce or at least some
supporting data, there's not much one can learn from this, except that
the problem is not yet solved.  If I modify a file outside Emacs and
then try to insert a character, and when Emacs asks the question, tell
it to revert its buffer, I see no crashes.

> Finsert_file_contents at fileio.c:4019
> Ffuncall at eval.c:2821
> exec_byte_code at bytecode.c:919
> funcall_lambda at eval.c:2973
> Ffuncall at eval.c:2854
> exec_byte_code at bytecode.c:919
> funcall_lambda at eval.c:2973
> Ffuncall at eval.c:2854
> exec_byte_code at bytecode.c:919
> funcall_lambda at eval.c:2973
> Ffuncall at eval.c:2854
> exec_byte_code at bytecode.c:919
> funcall_lambda at eval.c:3039
> Ffuncall at eval.c:2854
> call1 at eval.c:2604
> lock_file at filelock.c:709
> prepare_to_modify_buffer_1 at insdel.c:1841
> prepare_to_modify_buffer at insdel.c:1876
> insert_1_both at insdel.c:797
> insert_and_inherit at insdel.c:593
> internal_self_insert at cmds.c:489
> Fself_insert_command at cmds.c:310
> Ffuncall at eval.c:2805
> Fcall_interactively at callint.c:836

What I see from this backtrace is that you typed a characters
(self-insert-command), to which Emacs told you that the file was
modified and asked what to do.  You then replied with 'r', asking
Emacs to revert the buffer.  As result of the revert, some
after-change-hook got run, which caused another (perhaps the same)
after-change-hook to run:

> Fline_beginning_position at editfns.c:772
> Ffuncall at eval.c:2805
> exec_byte_code at bytecode.c:919
> funcall_lambda at eval.c:3039
> Ffuncall at eval.c:2854
> funcall_nil at eval.c:2356
> run_hook_with_args at eval.c:2541
> Frun_hook_with_args at eval.c:2402 <<<<<<<<<<<<<<<<<<<<<
> Ffuncall at eval.c:2786
> exec_byte_code at bytecode.c:919
> funcall_lambda at eval.c:2973
> Ffuncall at eval.c:2854
> funcall_nil at eval.c:2356
> run_hook_with_args at eval.c:2541
> Frun_hook_with_args at eval.c:2402 <<<<<<<<<<<<<<<<<<<<<<<<
> signal_after_change at insdel.c:2081
> del_range_byte at insdel.c:1637
> Finsert_file_contents at fileio.c:4019

Any idea what could those hooks be?

In general, if you want to help the investigation, run Emacs under
GDB, and when this happens look around to find answers to these
questions.

TIA.

bug#15893: 24.3.50; emacs_backtrace

[Eli Zaretskii]

> Date: Tue, 26 Nov 2013 19:19:28 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 15893@debbugs.gnu.org
> 
> > Date: Tue, 26 Nov 2013 14:57:52 +0100
> > From: Dani Moncayo <dmoncayo@gmail.com>
> > 
> > >> > If you can recall what were you doing when this happened, please tell.
> > >>
> > >> Reverting a buffer which was updated by another program.
> > >
> > > Thanks.
> > 
> > FWIW: Today (with an Emacs build yesterday from trunk) I've got two
> > more crashes while reverting buffers.
> 
> Thanks.  However, without a recipe to reproduce or at least some
> supporting data, there's not much one can learn from this, except that
> the problem is not yet solved.  If I modify a file outside Emacs and
> then try to insert a character, and when Emacs asks the question, tell
> it to revert its buffer, I see no crashes.

Please try the current trunk, the changes I made in revision 115259
might also fix this one.

bug#15893: 24.3.50; emacs_backtrace

[Dani Moncayo]

> Please try the current trunk, the changes I made in revision 115259
> might also fix this one.

For a couple of days, I've used a binary with that changes, and I've
not seen more crashes since then (but the crashes were not
deterministic anyway).

So perhaps we could close this bug now, and I'll reopen it if I see
the crash again.

Thanks.

-- 
Dani Moncayo

bug#15893: 24.3.50; emacs_backtrace

[Eli Zaretskii]

> Date: Fri, 29 Nov 2013 10:27:56 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 15893@debbugs.gnu.org
> 
> > Please try the current trunk, the changes I made in revision 115259
> > might also fix this one.
> 
> For a couple of days, I've used a binary with that changes, and I've
> not seen more crashes since then (but the crashes were not
> deterministic anyway).
> 
> So perhaps we could close this bug now, and I'll reopen it if I see
> the crash again.

Done.

Thanks.