bug#16207: 24.3.50; emacs_backtrace.txt

bug#16207: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> > Backtrace:
> > 011f90c2
> 
> Where are my first 2 lines in the file, which show the exception and
> its address?  They come before the "Backtrace" part.  Were they
> absent, or did you omit them from your post?

I posted the complete contents of the file, using `insert-file'.

bug#16207: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Sat, 21 Dec 2013 08:22:54 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 16207@debbugs.gnu.org
> 
> > > Backtrace:
> > > 011f90c2
> > 
> > Where are my first 2 lines in the file, which show the exception and
> > its address?  They come before the "Backtrace" part.  Were they
> > absent, or did you omit them from your post?
> 
> I posted the complete contents of the file, using `insert-file'.

Too bad.  Thanks.

bug#16207: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> Can you please show a recipe starting with "emacs -Q"?  The backtrace
> makes no sense at all: it shows call sequences that don't exist in the
> sources.  So a reproducible recipe is our only hope.
> 
> Please be as detailed in the recipe as you can.  E.g., please tell
> exactly how did you "widen the frame with the mouse" -- which portion
> of the frame did you drag and in what direction.

emacs -Q

(Well actually, my Windows shortcut for -Q has it open a directory with
Dired.)

M-x load-library pp.el

M-x debug-on-entry pp-eval-expression

M-x pp-eval-expression global-map

In debugger, hit `d' once or twice.

Then grab the right frame edge and pull it to the right a few inches.

Hit `d' -> crash.

bug#16207: 24.3.50; emacs_backtrace.txt

[Juanma Barranquero]

lisp.h:874: Emacs fatal error: assertion failed: BUFFERP (a)

Breakpoint 1, terminate_due_to_signal (sig=22,
backtrace_limit=2147483647) at emacs.c:351
351       signal (sig, SIG_DFL);
(gdb) bt
#0  terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:351
#1  0x011615dc in die (msg=0x148b198 "BUFFERP (a)", file=0x148b10c
"lisp.h", line=874) at alloc.c:6742
#2  0x010eb7fb in XBUFFER (a=58132514) at lisp.h:874
#3  0x01089e14 in run_window_configuration_change_hook (f=0x3aa1a08
<__register_frame_info+61479432>) at window.c:3257
#4  0x0100e79c in change_frame_size_1 (f=0x3aa1a08
<__register_frame_info+61479432>, new_width=824, new_height=608,
pretend=false, delay=false, safe=false,
    pixelwise=true) at dispnew.c:5588
#5  0x0100e27f in change_frame_size (f=0x3aa1a08
<__register_frame_info+61479432>, new_width=824, new_height=608,
pretend=false, delay=false, safe=false,
    pixelwise=true) at dispnew.c:5457
#6  0x01090ff6 in Fset_window_configuration (configuration=86847613)
at window.c:6233
#7  0x0117f87f in Ffuncall (nargs=2, args=0x88db24) at eval.c:2805
#8  0x011c0344 in exec_byte_code (bytestr=58650753, vector=86847981,
maxdepth=12, args_template=0, nargs=0, args=0x88de54) at
bytecode.c:919
#9  0x01180061 in funcall_lambda (fun=86848077, nargs=0,
arg_vector=0x88de54) at eval.c:2973
#10 0x0117fabb in Ffuncall (nargs=1, args=0x88de50) at eval.c:2854
#11 0x0117e3e7 in eval_sub (form=62132246) at eval.c:2147
#12 0x0117a078 in Fprogn (body=62132254) at eval.c:458
#13 0x0117a0e0 in unwind_body (body=62132254) at eval.c:472
#14 0x01180c08 in unbind_to (count=26, value=58132514) at eval.c:3296
#15 0x011c03e7 in exec_byte_code (bytestr=58732321, vector=58472509,
maxdepth=172, args_template=512, nargs=1, args=0x88e408) at
bytecode.c:941
#16 0x01180061 in funcall_lambda (fun=58472829, nargs=1,
arg_vector=0x88e408) at eval.c:2973
#17 0x0117fabb in Ffuncall (nargs=2, args=0x88e404) at eval.c:2854
#18 0x0117ea0f in Fapply (nargs=2, args=0x88e404) at eval.c:2291
#19 0x0117f315 in apply1 (fn=58262082, arg=62135166) at eval.c:2578
#20 0x01179b88 in call_debugger (arg=62135166) at eval.c:322
#21 0x01179be6 in do_debug_on_call (code=58183842) at eval.c:338
#22 0x0117f61b in Ffuncall (nargs=2, args=0x88e61c) at eval.c:2759
#23 0x0117ea0f in Fapply (nargs=2, args=0x88e61c) at eval.c:2291
#24 0x0117f76f in Ffuncall (nargs=3, args=0x88e618) at eval.c:2786
#25 0x011c0344 in exec_byte_code (bytestr=60319409, vector=62168693,
maxdepth=16, args_template=512, nargs=1, args=0x88e9a8) at
bytecode.c:919
#26 0x01180061 in funcall_lambda (fun=61883925, nargs=1,
arg_vector=0x88e9a8) at eval.c:2973
#27 0x0117fabb in Ffuncall (nargs=2, args=0x88e9a4) at eval.c:2854
#28 0x0117ea0f in Fapply (nargs=2, args=0x88e9a4) at eval.c:2291
#29 0x0117f315 in apply1 (fn=60622306, arg=62140750) at eval.c:2578
#30 0x011776de in Fcall_interactively (function=60622306,
record_flag=60294018, keys=58153845) at callint.c:378
#31 0x0117f8d4 in Ffuncall (nargs=4, args=0x88ebdc) at eval.c:2812
#32 0x011c0344 in exec_byte_code (bytestr=19806545, vector=19806565,
maxdepth=52, args_template=4100, nargs=2, args=0x88ef30) at
bytecode.c:919
#33 0x01180061 in funcall_lambda (fun=19806525, nargs=2,
arg_vector=0x88ef28) at eval.c:2973
#34 0x0117fabb in Ffuncall (nargs=3, args=0x88ef24) at eval.c:2854
#35 0x011c0344 in exec_byte_code (bytestr=19806217, vector=19806237,
maxdepth=60, args_template=2052, nargs=2, args=0x88f26c) at
bytecode.c:919
#36 0x01180061 in funcall_lambda (fun=19806189, nargs=2,
arg_vector=0x88f264) at eval.c:2973
#37 0x0117fabb in Ffuncall (nargs=3, args=0x88f260) at eval.c:2854
#38 0x0117ede0 in Fapply (nargs=2, args=0x88f2e4) at eval.c:2344
#39 0x0117f315 in apply1 (fn=58340930, arg=60849846) at eval.c:2578
#40 0x011776de in Fcall_interactively (function=58340930,
record_flag=58132514, keys=58153845) at callint.c:378
#41 0x0117f8d4 in Ffuncall (nargs=4, args=0x88f51c) at eval.c:2812
#42 0x011c0344 in exec_byte_code (bytestr=19806545, vector=19806565,
maxdepth=52, args_template=4100, nargs=1, args=0x88f860) at
bytecode.c:919
#43 0x01180061 in funcall_lambda (fun=19806525, nargs=1,
arg_vector=0x88f85c) at eval.c:2973
#44 0x0117fabb in Ffuncall (nargs=2, args=0x88f858) at eval.c:2854
#45 0x0117f36a in call1 (fn=58178658, arg1=58340930) at eval.c:2604
#46 0x010f3c29 in command_loop_1 () at keyboard.c:1552
#47 0x0117c765 in internal_condition_case (bfun=0x10f35c5
<command_loop_1>, handlers=58183970, hfun=0x10f2e2b <cmd_error>) at
eval.c:1344
#48 0x010f327a in command_loop_2 (ignore=58132514) at keyboard.c:1170
#49 0x0117bd12 in internal_catch (tag=58179330, func=0x10f3256
<command_loop_2>, arg=58132514) at eval.c:1108
#50 0x010f3232 in command_loop () at keyboard.c:1149
#51 0x010f29c8 in recursive_edit_1 () at keyboard.c:777
#52 0x010f2b84 in Frecursive_edit () at keyboard.c:841
#53 0x010f0d7c in main (argc=2, argv=0xbb1b20) at emacs.c:1634

Lisp Backtrace:
"set-window-configuration" (0x88db28)
0x52d3248 PVEC_COMPILED
"funcall" (0x88de50)
"debug" (0x88e408)
0x37cb620 PVEC_COMPILED
"apply" (0x88e61c)
"pp-eval-expression" (0x88e9a8)
"call-interactively" (0x88ebe0)
"command-execute" (0x88ef28)
"execute-extended-command" (0x88f264)
"call-interactively" (0x88f520)
"command-execute" (0x88f85c)
(gdb)

bug#16207: 24.3.50; emacs_backtrace.txt

[martin rudalics]

 > Breakpoint 1, terminate_due_to_signal (sig=22,
 > backtrace_limit=2147483647) at emacs.c:351
 > 351       signal (sig, SIG_DFL);
 > (gdb) bt
 > #0  terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:351
 > #1  0x011615dc in die (msg=0x148b198 "BUFFERP (a)", file=0x148b10c
 > "lisp.h", line=874) at alloc.c:6742
 > #2  0x010eb7fb in XBUFFER (a=58132514) at lisp.h:874
 > #3  0x01089e14 in run_window_configuration_change_hook (f=0x3aa1a08
 > <__register_frame_info+61479432>) at window.c:3257
...
 > "set-window-configuration" (0x88db28)

The selected window doesn't have a buffer.  I have no idea how to track
this down.  Basically, we'd have to record in some variable a triple
<operation executed, selected window, its buffer> whenever we (1) select
a window, (2) delete a window, (3) kill a buffer, and check at strategic
positions (e.g. as above in run_window_configuration_change_hook)
whether this variable contains something fishy and put that variable's
value somewhere before aborting.  Tedious ...

martin

bug#16207: 24.3.50; emacs_backtrace.txt

[martin rudalics]

 >  > Breakpoint 1, terminate_due_to_signal (sig=22,
 >  > backtrace_limit=2147483647) at emacs.c:351
 >  > 351       signal (sig, SIG_DFL);
 >  > (gdb) bt
 >  > #0  terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at
 > emacs.c:351
 >  > #1  0x011615dc in die (msg=0x148b198 "BUFFERP (a)", file=0x148b10c
 >  > "lisp.h", line=874) at alloc.c:6742
 >  > #2  0x010eb7fb in XBUFFER (a=58132514) at lisp.h:874
 >  > #3  0x01089e14 in run_window_configuration_change_hook (f=0x3aa1a08
 >  > <__register_frame_info+61479432>) at window.c:3257
 > ...
 >  > "set-window-configuration" (0x88db28)

Which is obviously bug#16051 which I've been now able to reproduce for
the first time.  And it's definitively the toolbar-window which causes
the crash.  And I can get it crash or loop forever (no C-g exit) on my
Gtk build too.

martin

bug#16207: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Sat, 21 Dec 2013 19:31:47 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: 16207@debbugs.gnu.org
> 
>  >  > Breakpoint 1, terminate_due_to_signal (sig=22,
>  >  > backtrace_limit=2147483647) at emacs.c:351
>  >  > 351       signal (sig, SIG_DFL);
>  >  > (gdb) bt
>  >  > #0  terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at
>  > emacs.c:351
>  >  > #1  0x011615dc in die (msg=0x148b198 "BUFFERP (a)", file=0x148b10c
>  >  > "lisp.h", line=874) at alloc.c:6742
>  >  > #2  0x010eb7fb in XBUFFER (a=58132514) at lisp.h:874
>  >  > #3  0x01089e14 in run_window_configuration_change_hook (f=0x3aa1a08
>  >  > <__register_frame_info+61479432>) at window.c:3257
>  > ...
>  >  > "set-window-configuration" (0x88db28)
> 
> Which is obviously bug#16051 which I've been now able to reproduce for
> the first time.  And it's definitively the toolbar-window which causes
> the crash.

But then the XBUFFER thing is bogus, because the tool-bar window never
has a buffer.  Its 'contents' field is always nil.

But how did that window get to become the "selected" window??  It
should never be that, I think.

bug#16207: 24.3.50; emacs_backtrace.txt

[martin rudalics]

 >> Which is obviously bug#16051 which I've been now able to reproduce for
 >> the first time.  And it's definitively the toolbar-window which causes
 >> the crash.

Too silly - I sent my message to the 16207 thread and meant to send it
to the 16051 one where you already remarked my missing insight.

So please disregard the remarks Eli cited on top of this mail in the
current thread: The toolbar window is by no means involved and neither
is this bug related to bug#16051.

 > But then the XBUFFER thing is bogus, because the tool-bar window never
 > has a buffer.  Its 'contents' field is always nil.

If the toolbar window ended up here, something crazy would have happened
indeed.

martin

bug#16207: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Sat, 21 Dec 2013 18:15:14 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: 16207@debbugs.gnu.org
> 
>  > Breakpoint 1, terminate_due_to_signal (sig=22,
>  > backtrace_limit=2147483647) at emacs.c:351
>  > 351       signal (sig, SIG_DFL);
>  > (gdb) bt
>  > #0  terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:351
>  > #1  0x011615dc in die (msg=0x148b198 "BUFFERP (a)", file=0x148b10c
>  > "lisp.h", line=874) at alloc.c:6742
>  > #2  0x010eb7fb in XBUFFER (a=58132514) at lisp.h:874
>  > #3  0x01089e14 in run_window_configuration_change_hook (f=0x3aa1a08
>  > <__register_frame_info+61479432>) at window.c:3257
> ...
>  > "set-window-configuration" (0x88db28)
> 
> The selected window doesn't have a buffer.  I have no idea how to track
> this down.

Maybe one way is to think how could this happen, ever.  How can such
window even exist?

bug#16207: 24.3.50; emacs_backtrace.txt

[martin rudalics]

> Maybe one way is to think how could this happen, ever.  How can such
> window even exist?

I think I know what's causing it.  But I have to do some testing
before checking in a fix.

In any case, don't bother about this until you hear from me.

martin

bug#16207: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Sat, 21 Dec 2013 20:58:49 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: lekktu@gmail.com, 16207@debbugs.gnu.org
> 
> > Maybe one way is to think how could this happen, ever.  How can such
> > window even exist?
> 
> I think I know what's causing it.  But I have to do some testing
> before checking in a fix.

Great, thanks.

bug#16207: 24.3.50; emacs_backtrace.txt

[martin rudalics]

 > I think I know what's causing it.  But I have to do some testing
 > before checking in a fix.

Rather than spending hours to test this I checked in a fix.  This way we
should find out soon enough whether it breaks anything else.

In this context I wonder what the variable inhibit_lisp_code stands for.
Initially, it was called inhibit_window_configuration_change_hook and
did exactly what its name said.  Then it moved to eval.c, got its new
name, but still does what it did before.  So if we want this to really
inihibit running Lisp code we should obey it in each and every hook
(although I fail to understand why we can't bind Vrun_hooks instead).
Otherwise, we should probably give it back its initial name to avoid
confusions.  WDYT?

martin

bug#16207: 24.3.50; emacs_backtrace.txt

[Juanma Barranquero]

On Sun, Dec 22, 2013 at 4:37 PM, martin rudalics <rudalics@gmx.at> wrote:

> Rather than spending hours to test this I checked in a fix.  This way we
> should find out soon enough whether it breaks anything else.

I'm bootstrapping a new binary for Drew to try, it'll be up ASAP.

   J

bug#16207: 24.3.50; emacs_backtrace.txt

[martin rudalics]

> I'm bootstrapping a new binary for Drew to try, it'll be up ASAP.

Belated thanks.

martin

bug#16207: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> Rather than spending hours to test this I checked in a fix.  This way we
> should find out soon enough whether it breaks anything else.
> 
> In this context I wonder what the variable inhibit_lisp_code stands for.
> Initially, it was called inhibit_window_configuration_change_hook and
> did exactly what its name said.  Then it moved to eval.c, got its new
> name, but still does what it did before.  So if we want this to really
> inihibit running Lisp code we should obey it in each and every hook
> (although I fail to understand why we can't bind Vrun_hooks instead).
> Otherwise, we should probably give it back its initial name to avoid
> confusions.  WDYT?

I tested with this version, and it seems to be fixed.  Thx.

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-12-22 on ODIEONE
Bzr revision: 115700 xfq.free@gmail.com-20131222231942-q8ftfeg3ft2a1t83
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3' CPPFLAGS=-Ic:/Devel/emacs/include
 LDFLAGS=-Lc:/Devel/emacs/lib'

bug#16207: 24.3.50; emacs_backtrace.txt

[martin rudalics]

> I tested with this version, and it seems to be fixed.  Thx.

Bug closed.

Thanks, martin

bug#16207: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Sun, 22 Dec 2013 16:37:36 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: lekktu@gmail.com, 16207@debbugs.gnu.org, Chong Yidong <cyd@gnu.org>
> 
>  > I think I know what's causing it.  But I have to do some testing
>  > before checking in a fix.
> 
> Rather than spending hours to test this I checked in a fix.  This way we
> should find out soon enough whether it breaks anything else.

Thanks!

> In this context I wonder what the variable inhibit_lisp_code stands for.
> Initially, it was called inhibit_window_configuration_change_hook and
> did exactly what its name said.  Then it moved to eval.c, got its new
> name, but still does what it did before.  So if we want this to really
> inihibit running Lisp code we should obey it in each and every hook
> (although I fail to understand why we can't bind Vrun_hooks instead).
> Otherwise, we should probably give it back its initial name to avoid
> confusions.  WDYT?

If you are asking me, then there's nothing intelligent I can say about
this issue: I didn't rename the variable and didn't even notice it got
renamed.

bug#16207: 24.3.50; emacs_backtrace.txt

[martin rudalics]

> If you are asking me, then there's nothing intelligent I can say about
> this issue: I didn't rename the variable and didn't even notice it got
> renamed.

IIUC Chong invented the variable and renamed it.  That's why I was
CC-ing him.

martin

bug#16207: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sat, 21 Dec 2013 17:53:29 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, 16207@debbugs.gnu.org
> 
> lisp.h:874: Emacs fatal error: assertion failed: BUFFERP (a)
> 
> Breakpoint 1, terminate_due_to_signal (sig=22,
> backtrace_limit=2147483647) at emacs.c:351
> 351       signal (sig, SIG_DFL);
> (gdb) bt
> #0  terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:351
> #1  0x011615dc in die (msg=0x148b198 "BUFFERP (a)", file=0x148b10c
> "lisp.h", line=874) at alloc.c:6742

Thanks.  What does "xtype" say about this 'a' that was expected to be
a buffer?

bug#16207: 24.3.50; emacs_backtrace.txt

[Juanma Barranquero]

On Sat, Dec 21, 2013 at 7:46 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> What does "xtype" say about this 'a' that was expected to be a buffer?

(gdb) frame 2
#2  0x010eb7fb in XBUFFER (a=58132514) at lisp.h:874
874       eassert (BUFFERP (a));
(gdb) p a
$1 = 58132514
(gdb) xtype
Lisp_Symbol
(gdb)

bug#16207: 24.3.50; emacs_backtrace.txt

[Juanma Barranquero]

On Sat, Dec 21, 2013 at 7:50 PM, Juanma Barranquero <lekktu@gmail.com> wrote:

> Lisp_Symbol

nil, BTW

  J

bug#16207: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Sat, 21 Dec 2013 20:46:25 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 16207@debbugs.gnu.org
> 
> > #1  0x011615dc in die (msg=0x148b198 "BUFFERP (a)", file=0x148b10c
> > "lisp.h", line=874) at alloc.c:6742
> 
> Thanks.  What does "xtype" say about this 'a' that was expected to be
> a buffer?

I'm guessing it's a symbol nil.

bug#16207: 24.3.50; emacs_backtrace.txt

[Drew Adams]

Here is the backtrace I got with that recipe.  Dunno why the first file I included ended with `...'.  This one starts out the same, anyway.  HTH.


Backtrace:
011f90c2
011f9134
010edc19
0115fe24
010e9bab
0108856c
0100e6c5
0100e1a8
0108f611
0117e030
011be773
0117e812
0117e26c
0117cb98
0117884c
011788b4
0117f394
011be816
0117e812
0117e26c
0117d1c0
0117dac6
0117835c
011783ba
0117ddcc
0117d1c0
0117df20
011be773
0117e812
0117e26c
0117d1c0
0117dac6
01175eaa
0117e085
011be773
0117e812
0117e26c
011be773
0117e812
0117e26c
0117d591
0117dac6
01175eaa
0117e085
011be773
0117e812
0117e26c
0117db1b
010f1fa8
0117af2c
010f15fc
0117a4d9
010f15b4
010f0d4c
010f0f08
010ef113
010010f9
76f43366
77899f6e
77899f41

bug#16207: 24.3.50; emacs_backtrace.txt

[Drew Adams]

Backtrace:
011f90c2
011f9134
010edc19
0115fe24
010e9bab
0108856c
0100e6c5
0100e1a8
0108f611
0117e030
011be773
0117e812
0117e26c
0117cb98
0117884c
011788b4
0117f394
011be816
0117e812
0117e26c
0117d591
0117dac6
0117835c
0117d0d8
0117884c
01179fd7
0117ca06
0117884c
01178799
0117ca06
0117884c
0117eb41
0117e33f
0117d591
0117df20
011be773
0117e812
0117e26c
0117d591
0117cb98
0117884c
0117eb41
0117e33f
011be773
0117e812
0117e26c
011be773
0117e812
0117e26c
011be773
0117e812
0117e26c
011be773
0117e812
0117e26c
011be773
0117e812
0117e26c
0117d591
0117df20
011be773
0117e812
...




In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-12-16 on ODIEONE
Bzr revision: 115543 rudalics@gmx.at-20131216095844-lbjh5yerk6ff0tm7
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'

bug#16207: 24.3.50; emacs_backtrace.txt

[Drew Adams]

This is with emacs -Q.  I was in the debugger, and I widened the frame using the mouse.  That caused the crash.  Twice now - same backtrace.

bug#16207: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Fri, 20 Dec 2013 13:53:53 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> 
> This is with emacs -Q.  I was in the debugger, and I widened the frame using the mouse.  That caused the crash.  Twice now - same backtrace.

Can you please show a recipe starting with "emacs -Q"?  The backtrace
makes no sense at all: it shows call sequences that don't exist in the
sources.  So a reproducible recipe is our only hope.

Please be as detailed in the recipe as you can.  E.g., please tell
exactly how did you "widen the frame with the mouse" -- which portion
of the frame did you drag and in what direction.

Thanks.

bug#16207: 24.3.50; emacs_backtrace.txt

[Juanma Barranquero]

??
??:0
Ffile_system_info at w32fns.c:7436
Ffile_system_info at w32fns.c:7452
GLYPH_CODE_P at dispextern.h:1851
mark_object at alloc.c:5996
face_for_overlay_string at xfaces.c:6068
window_loop at window.c:2761
change_frame_size_1 at dispnew.c:5570
do_pending_window_change at dispnew.c:5413
Frecenter at window.c:5577
eval_sub at eval.c:2137
copy_executable_and_dump_data at unexw32.c:605
Fapply at eval.c:2316
eval_sub at eval.c:2189
xsignal2 at eval.c:1599
Fcall_interactively at callint.c:774
Fcall_interactively at callint.c:774
Ffuncall at eval.c:2778
copy_executable_and_dump_data at unexw32.c:615
Fapply at eval.c:2316
eval_sub at eval.c:2189
Fcommandp at eval.c:1850
grow_specpdl at eval.c:2021
Fcall_interactively at callint.c:679
maybe_call_debugger at eval.c:1714
Fcall_interactively at callint.c:774
Fsetq at eval.c:542
Fsignal at eval.c:1536
Fcall_interactively at callint.c:774
Fcall_interactively at callint.c:775
Fsignal at eval.c:1536
Fcall_interactively at callint.c:774
Frun_hook_with_args_until_success at eval.c:2422
eval_sub at eval.c:2199
Fcommandp at eval.c:1850
eval_sub at eval.c:2129
copy_executable_and_dump_data at unexw32.c:605
Fapply at eval.c:2316
eval_sub at eval.c:2189
Fcommandp at eval.c:1850
xsignal2 at eval.c:1599
Fcall_interactively at callint.c:774
Frun_hook_with_args_until_success at eval.c:2422
eval_sub at eval.c:2199
copy_executable_and_dump_data at unexw32.c:605
Fapply at eval.c:2316
eval_sub at eval.c:2189
copy_executable_and_dump_data at unexw32.c:605
Fapply at eval.c:2316
eval_sub at eval.c:2189
copy_executable_and_dump_data at unexw32.c:605
Fapply at eval.c:2316
eval_sub at eval.c:2189
copy_executable_and_dump_data at unexw32.c:605
Fapply at eval.c:2316
eval_sub at eval.c:2189
copy_executable_and_dump_data at unexw32.c:605
Fapply at eval.c:2316
eval_sub at eval.c:2189
Fcommandp at eval.c:1850
eval_sub at eval.c:2129
copy_executable_and_dump_data at unexw32.c:605
Fapply at eval.c:2316
??
??:0

bug#16207: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Fri, 20 Dec 2013 13:38:47 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> 
> 
> 
> Backtrace:
> 011f90c2

Where are my first 2 lines in the file, which show the exception and
its address?  They come before the "Backtrace" part.  Were they
absent, or did you omit them from your post?