bug#14389: 24.3.50; emacs_backtrace.txt

bug#14389: 24.3.50; emacs_backtrace.txt

[Drew Adams]

Backtrace:
0x011596ED
0x0115975F
0x010E82C7
0x0101596C
0x01015146
0x0101329A
0x0100F0E2
0x01015837
0x01014F59
0x010E517E
0x0101596C
0x01014E87
0x010141F5
0x011CA1B5
0x011CA735
0x011D3CA9
0x01016530
0x010E5C83
0x0101596C
0x01014E87
0x010E517E
0x0101596C
0x01014E87
0x010141F5
0x01025C4C
0x01010C39
0x0102606A
0x01014038
0x010260BE
0x0102486D
0x01010C39
0x01023814
0x01010696
0x0102377D
0x01022D88
0x010C2439
0x010C3143
0x01014D87
0x010E517E
0x0101596C
0x01014E87
0x010E517E
0x0101596C
0x01014E87
0x010E517E
0x010E454E
0x01012F1D
0x01010696
0x010E5D12
0x0101596C
0x01014E87
0x010E517E
0x0101596C
0x01014E87
0x01012C92
0x01010B57
0x010E5DBB
0x0101596C
0x01014E87
0x010141A0
0x010E8FF2
0x01014B45
...
 
Backtrace:
0x011594ED
0x0115955F
0x01001459
0x01021A5E
0x0114F2B6
0x7E418730
0x7E418812
0x7E4189C9
0x7E418A0C
0x0114DB00
0x0114DD9F
0x7C80B725
 
 
 

In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
 of 2013-05-10 on ODIEONE
Bzr revision: 112542 rgm@gnu.org-20130510102119-fklj7xlajezey0tr
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -IC:/Devel/emacs/build/include --ldflags -LC:/Devel/emacs/build/lib'
 

bug#13980: bug#14389: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sat, 11 May 2013 13:01:55 -0700
> 
> Backtrace:
> 0x011596ED
> 0x0115975F
> 0x010E82C7
> 0x0101596C
> 0x01015146
> 0x0101329A
> 0x0100F0E2
> 0x01015837
> 0x01014F59
> 0x010E517E
> 0x0101596C
> 0x01014E87
> 0x010141F5
> 0x011CA1B5
> 0x011CA735
> 0x011D3CA9
> 0x01016530
> 0x010E5C83
> 0x0101596C
> 0x01014E87
> 0x010E517E
> 0x0101596C
> 0x01014E87
> 0x010141F5
> 0x01025C4C
> 0x01010C39
> 0x0102606A
> 0x01014038
> 0x010260BE
> 0x0102486D
> 0x01010C39
> 0x01023814
> 0x01010696
> 0x0102377D
> 0x01022D88
> 0x010C2439
> 0x010C3143
> 0x01014D87
> 0x010E517E
> 0x0101596C
> 0x01014E87
> 0x010E517E
> 0x0101596C
> 0x01014E87
> 0x010E517E
> 0x010E454E
> 0x01012F1D
> 0x01010696
> 0x010E5D12
> 0x0101596C
> 0x01014E87
> 0x010E517E
> 0x0101596C
> 0x01014E87
> 0x01012C92
> 0x01010B57
> 0x010E5DBB
> 0x0101596C
> 0x01014E87
> 0x010141A0
> 0x010E8FF2
> 0x01014B45
> ...

I think this part was with an earlier binary, not the one you reported
(because the result of using this backtrace doesn't make any sense at
all).  What was the previous version you used?  My guess is it was
emacs-20130502-r112438-bin-i386.zip, which brings us to something very
similar to bug #14236, #13154, and #13980:

  emacs_abort at C:\Devel\emacs\repo\build\src/w32fns.c:7822
  emacs_abort at C:\Devel\emacs\repo\build\src/w32fns.c:7831
  exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:1958
  funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2906
  apply_lambda at C:\Devel\emacs\repo\build\src/eval.c:2783
  eval_sub at C:\Devel\emacs\repo\build\src/eval.c:2084
  Fprogn at C:\Devel\emacs\repo\build\src/eval.c:359
  funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2899
  Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2735
  exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:900
  funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2906
  Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2723
  call0 at C:\Devel\emacs\repo\build\src/eval.c:2453
  select_frame_norecord at C:\Devel\emacs\repo\build\src/window.c:3091
  set_window_buffer at C:\Devel\emacs\repo\build\src/window.c:3177
  delete_all_child_windows at C:\Devel\emacs\repo\build\src/window.c:5885
  unbind_to at C:\Devel\emacs\repo\build\src/eval.c:3097
  exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:1066
  funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2906
  Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2723
  exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:900
  funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2906
  Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2723
  call0 at C:\Devel\emacs\repo\build\src/eval.c:2453
  safe_run_hooks_1 at C:\Devel\emacs\repo\build\src/keyboard.c:1875
  internal_condition_case at C:\Devel\emacs\repo\build\src/eval.c:1193
  safe_run_hook_funcall at C:\Devel\emacs\repo\build\src/keyboard.c:1930
  run_hook_with_args at C:\Devel\emacs\repo\build\src/eval.c:2398
  safe_run_hooks at C:\Devel\emacs\repo\build\src/keyboard.c:1947
  command_loop_1 at C:\Devel\emacs\repo\build\src/keyboard.c:1592
  internal_condition_case at C:\Devel\emacs\repo\build\src/eval.c:1193
  command_loop_2 at C:\Devel\emacs\repo\build\src/keyboard.c:1167
  internal_catch at C:\Devel\emacs\repo\build\src/eval.c:964
  command_loop at C:\Devel\emacs\repo\build\src/keyboard.c:1138
  recursive_edit_1 at C:\Devel\emacs\repo\build\src/keyboard.c:779
  read_minibuf at C:\Devel\emacs\repo\build\src/minibuf.c:678
  Fread_from_minibuffer at C:\Devel\emacs\repo\build\src/minibuf.c:980
  Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2700
  exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:900
  funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2906
  Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2723
  exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:900
  funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2906
  Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2723
  exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:900
  Fbyte_code at C:\Devel\emacs\repo\build\src/bytecode.c:475
  eval_sub at C:\Devel\emacs\repo\build\src/eval.c:2045
  internal_catch at C:\Devel\emacs\repo\build\src/eval.c:964
  exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:1081
  funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2906
  Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2723
  exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:900
  funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2906
  Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2723
  eval_sub at C:\Devel\emacs\repo\build\src/eval.c:2011
  internal_lisp_condition_case at C:\Devel\emacs\repo\build\src/eval.c:1147
  exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:1096
  funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2906
  Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2723
  apply1 at C:\Devel\emacs\repo\build\src/eval.c:2435
  Fcall_interactively at C:\Devel\emacs\repo\build\src/callint.c:378
  Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2681

> Backtrace:
> 0x011594ED
> 0x0115955F
> 0x01001459
> 0x01021A5E
> 0x0114F2B6
> 0x7E418730
> 0x7E418812
> 0x7E4189C9
> 0x7E418A0C
> 0x0114DB00
> 0x0114DD9F
> 0x7C80B725

This part translates into this:

  w32_backtrace at C:\Devel\emacs\repo\build\src/w32fns.c:7739
  emacs_abort at C:\Devel\emacs\repo\build\src/w32fns.c:7771
  terminate_due_to_signal at C:\Devel\emacs\repo\build\src/emacs.c:343
  die at C:\Devel\emacs\repo\build\src/alloc.c:6522
  w32_wnd_proc at C:\Devel\emacs\repo\build\src/w32fns.c:3187

Which means my fix for bug #14062 did not solve it.  Hmm...

bug#14062: bug#14389: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> I think this part was with an earlier binary, not the one you reported
> (because the result of using this backtrace doesn't make any sense at
> all).

I don't think so.  After the crash I brought up the same version to report it.

I typically use only one Emacs 24 build at a time, the latest one I have (unless
it is totally unusable).

If I ever mistake the version (e.g. what crashed vs what I reported from) then
it would likely be a completely different release (e.g. Emacs 23 vs 24).  Not
necessarily, but likely.

> What was the previous version you used?

The previous binary I have to the one I reported about (from 5/10), is from 5/4:

In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
 of 2013-05-04 on ODIEONE
Bzr revision: 112449 monnier@iro.umontreal.ca-20130504193419-kbd4imjj1yxr5ksz
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -IC:/Devel/emacs/build/include --ldflags -LC:/Devel/emacs/build/lib'

> My guess is it was
> emacs-20130502-r112438-bin-i386.zip, which brings us to something very
> similar to bug #14236, #13154, and #13980

No, I have no binary from 5/2. The one I have prior to 5/4 is from 4/26.

HTH.

bug#14389: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <14389@debbugs.gnu.org>, <14062@debbugs.gnu.org>, <13980@debbugs.gnu.org>
> Date: Mon, 13 May 2013 11:07:08 -0700
> 
> > I think this part was with an earlier binary, not the one you reported
> > (because the result of using this backtrace doesn't make any sense at
> > all).
> 
> I don't think so.  After the crash I brought up the same version to report it.

But the file you sent included 2 different backtraces, so there were 2
crashes, not one.

> The previous binary I have to the one I reported about (from 5/10), is from 5/4:
> 
> In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
>  of 2013-05-04 on ODIEONE
> Bzr revision: 112449 monnier@iro.umontreal.ca-20130504193419-kbd4imjj1yxr5ksz
> Windowing system distributor `Microsoft Corp.', version 5.1.2600
> Configured using:
>  `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
>  -IC:/Devel/emacs/build/include --ldflags -LC:/Devel/emacs/build/lib'
> 
> > My guess is it was
> > emacs-20130502-r112438-bin-i386.zip, which brings us to something very
> > similar to bug #14236, #13154, and #13980
> 
> No, I have no binary from 5/2. The one I have prior to 5/4 is from 4/26.

Well, then maybe I'm mistaken.

bug#14389: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> > I don't think so.  After the crash I brought up the same 
> > version to report it.
> 
> But the file you sent included 2 different backtraces, so there were 2
> crashes, not one.

Really?  I try to delete file emacs_backtrace.txt after I report a crash.

(Maybe instead of appending to the same file, since the version is not recorded,
Emacs should create a separate file, emacs_backtrace<2>.txt etc.?)
 
> > No, I have no binary from 5/2. The one I have prior to 5/4 
> > is from 4/26.
> 
> Well, then maybe I'm mistaken.

I cannot guarantee that I reported using the same version as the one that
crashed.  But I think I did.

bug#14389: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> > > I don't think so.  After the crash I brought up the same 
> > > version to report it.
> > 
> > But the file you sent included 2 different backtraces, so 
> > there were 2 crashes, not one.
> 
> Really?  I try to delete file emacs_backtrace.txt after I 
> report a crash.
> 
> (Maybe instead of appending to the same file, since the 
> version is not recorded, Emacs should create a separate file,
> emacs_backtrace<2>.txt etc.?)

BTW - just a thought.  Sometimes, including for this bug, I get two fatal-error
dialog boxes.  Might that result in two backtraces in the same
emacs_backtrace.txt?

bug#14389: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <14389@debbugs.gnu.org>
> Date: Mon, 13 May 2013 12:32:52 -0700
> 
> BTW - just a thought.  Sometimes, including for this bug, I get two fatal-error
> dialog boxes.  Might that result in two backtraces in the same
> emacs_backtrace.txt?

Anything's possible when a program is crashing.  But the first
backtrace doesn't make sense at all, it points to code lines that
cannot possibly crash, like a simple assignment of a simple variable.

bug#14062: bug#14389: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Mon, 13 May 2013 20:33:13 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 14389@debbugs.gnu.org, 14062@debbugs.gnu.org, 13980@debbugs.gnu.org
> 
> > Backtrace:
> > 0x011594ED
> > 0x0115955F
> > 0x01001459
> > 0x01021A5E
> > 0x0114F2B6
> > 0x7E418730
> > 0x7E418812
> > 0x7E4189C9
> > 0x7E418A0C
> > 0x0114DB00
> > 0x0114DD9F
> > 0x7C80B725
> 
> This part translates into this:
> 
>   w32_backtrace at C:\Devel\emacs\repo\build\src/w32fns.c:7739
>   emacs_abort at C:\Devel\emacs\repo\build\src/w32fns.c:7771
>   terminate_due_to_signal at C:\Devel\emacs\repo\build\src/emacs.c:343
>   die at C:\Devel\emacs\repo\build\src/alloc.c:6522
>   w32_wnd_proc at C:\Devel\emacs\repo\build\src/w32fns.c:3187
> 
> Which means my fix for bug #14062 did not solve it.  Hmm...

Trunk revision 112580 is another attempt at solving this bug.