* bug#14631: 24.3.50; emacs_backtrace.txt
@ 2013-06-16 6:04 Drew Adams
2013-06-16 10:18 ` Juanma Barranquero
0 siblings, 1 reply; 6+ messages in thread
From: Drew Adams @ 2013-06-16 6:04 UTC (permalink / raw)
To: 14631
Backtrace:
0x012a35a7
0x012a3619
0x0112a3c0
0x011cd1bb
0x01299118
0x75d562f6
0x75d56d36
0x75d577c0
0x75d57886
0x01297914
0x01297bb3
0x774833a6
0x77be9eee
0x77be9ec1
Backtrace:
0x012a35a7
0x012a3619
0x0113ec1a
0x0113ec32
0x012c002f
0x012c00af
0x010186be
0x01043326
0x01042f1e
0x011e46d4
0x011f1a04
0x01256e20
0x011f2c0f
0x011f20c8
0x01256e20
0x011f2c0f
0x011f20c8
0x01256e20
0x011f27a7
0x011f20c8
0x01256e20
0x011f27a7
0x011f20c8
0x01256e20
0x011f27a7
0x011f20c8
0x01256e20
0x011f27a7
0x011f20c8
0x01256e20
0x011f27a7
0x011f20c8
0x01256e20
0x011f2c0f
0x011f20c8
0x011efe42
0x011edada
0x01257af0
0x011f2c0f
0x011f20c8
0x011f13d0
0x011e97fb
0x011f1d81
0x01256e20
0x011f27a7
0x011f20c8
0x011f1459
0x0112f548
0x011edbba
0x0112e4ff
0x011ed61a
0x0112e4b7
0x0112da61
0x0112dd9c
0x0112b950
0x010010f9
0x774833a6
0x77be9eee
0x77be9ec1
In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
of 2013-06-13 on ODIEONE
Bzr revision: 112978 xfq.free@gmail.com-20130613224333-3yfl8navh3c1vmxy
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''
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#14631: 24.3.50; emacs_backtrace.txt
2013-06-16 6:04 bug#14631: 24.3.50; emacs_backtrace.txt Drew Adams
@ 2013-06-16 10:18 ` Juanma Barranquero
2013-06-17 16:33 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Juanma Barranquero @ 2013-06-16 10:18 UTC (permalink / raw)
To: Drew Adams; +Cc: 14631
> Backtrace:
0x00000bac: ??
??:0
0x012a35a7: w32_backtrace at w32fns.c:7740
0x012a3619: emacs_abort at w32fns.c:7772
0x0112a3c0: terminate_due_to_signal at emacs.c:343
0x011cd1bb: die at alloc.c:6509
0x01299118: w32_wnd_proc at w32fns.c:3188
0x75d562f6: ??
??:0
0x75d56d36: ??
??:0
0x75d577c0: ??
??:0
0x75d57886: ??
??:0
0x01297914: w32_msg_pump at w32fns.c:2517
0x01297bb3: w32_msg_worker@4 at w32fns.c:2643
0x774833a6: ??
??:0
0x77be9eee: ??
??:0
0x77be9ec1: ??
??:0
> Backtrace:
0x00000bac: ??
??:0
0x012a35a7: w32_backtrace at w32fns.c:7740
0x012a3619: emacs_abort at w32fns.c:7772
0x0113ec1a: unblock_input_to at keyboard.c:7121
0x0113ec32: unblock_input at keyboard.c:7132
0x012c002f: x_raise_frame at w32term.c:5926
0x012c00af: w32_frame_raise_lower at w32term.c:5948
0x010186be: Fraise_frame at frame.c:1777
0x01043326: message3_nolog at xdisp.c:9704
0x01042f1e: message3 at xdisp.c:9659
0x011e46d4: Fmessage at editfns.c:3462
0x011f1a04: Ffuncall at eval.c:2692
0x01256e20: exec_byte_code at bytecode.c:903
0x011f2c0f: funcall_lambda at eval.c:2945
0x011f20c8: Ffuncall at eval.c:2760
0x01256e20: exec_byte_code at bytecode.c:903
0x011f2c0f: funcall_lambda at eval.c:2945
0x011f20c8: Ffuncall at eval.c:2760
0x01256e20: exec_byte_code at bytecode.c:903
0x011f27a7: funcall_lambda at eval.c:2879
0x011f20c8: Ffuncall at eval.c:2760
0x01256e20: exec_byte_code at bytecode.c:903
0x011f27a7: funcall_lambda at eval.c:2879
0x011f20c8: Ffuncall at eval.c:2760
0x01256e20: exec_byte_code at bytecode.c:903
0x011f27a7: funcall_lambda at eval.c:2879
0x011f20c8: Ffuncall at eval.c:2760
0x01256e20: exec_byte_code at bytecode.c:903
0x011f27a7: funcall_lambda at eval.c:2879
0x011f20c8: Ffuncall at eval.c:2760
0x01256e20: exec_byte_code at bytecode.c:903
0x011f27a7: funcall_lambda at eval.c:2879
0x011f20c8: Ffuncall at eval.c:2760
0x01256e20: exec_byte_code at bytecode.c:903
0x011f2c0f: funcall_lambda at eval.c:2945
0x011f20c8: Ffuncall at eval.c:2760
0x011efe42: eval_sub at eval.c:2053
0x011edada: internal_lisp_condition_case at eval.c:1169
0x01257af0: exec_byte_code at bytecode.c:1099
0x011f2c0f: funcall_lambda at eval.c:2945
0x011f20c8: Ffuncall at eval.c:2760
0x011f13d0: apply1 at eval.c:2477
0x011e97fb: Fcall_interactively at callint.c:381
0x011f1d81: Ffuncall at eval.c:2718
0x01256e20: exec_byte_code at bytecode.c:903
0x011f27a7: funcall_lambda at eval.c:2879
0x011f20c8: Ffuncall at eval.c:2760
0x011f1459: call1 at eval.c:2510
0x0112f548: command_loop_1 at keyboard.c:1575
0x011edbba: internal_condition_case at eval.c:1214
0x0112e4ff: command_loop_2 at keyboard.c:1164
0x011ed61a: internal_catch at eval.c:988
0x0112e4b7: command_loop at keyboard.c:1143
0x0112da61: recursive_edit_1 at keyboard.c:776
0x0112dd9c: Frecursive_edit at keyboard.c:840
0x0112b950: main at emacs.c:1543
0x010010f9: ?? at crt1.c:0
0x774833a6: ??
??:0
0x77be9eee: ??
??:0
0x77be9ec1: ??
??:0
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#14631: 24.3.50; emacs_backtrace.txt
2013-06-16 10:18 ` Juanma Barranquero
@ 2013-06-17 16:33 ` Eli Zaretskii
2013-06-18 7:20 ` martin rudalics
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2013-06-17 16:33 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: 14631
> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sun, 16 Jun 2013 12:18:32 +0200
> Cc: 14631@debbugs.gnu.org
>
> 0x012a35a7: w32_backtrace at w32fns.c:7740
> 0x012a3619: emacs_abort at w32fns.c:7772
> 0x0113ec1a: unblock_input_to at keyboard.c:7121
> 0x0113ec32: unblock_input at keyboard.c:7132
This is because we somehow call unblock_input more than we call
block_input. Do we have any facilities to find out where this
happens? Stefan? anyone?
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#14631: 24.3.50; emacs_backtrace.txt
2013-06-17 16:33 ` Eli Zaretskii
@ 2013-06-18 7:20 ` martin rudalics
2013-06-18 16:02 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: martin rudalics @ 2013-06-18 7:20 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 14631, Juanma Barranquero
> This is because we somehow call unblock_input more than we call
> block_input. Do we have any facilities to find out where this
> happens? Stefan? anyone?
Add parameters to block_input and unblock_input to remember where they
were called from. I think that such an investment should pay off in the
long run.
martin
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#14631: 24.3.50; emacs_backtrace.txt
2013-06-18 7:20 ` martin rudalics
@ 2013-06-18 16:02 ` Eli Zaretskii
2013-06-18 19:32 ` martin rudalics
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2013-06-18 16:02 UTC (permalink / raw)
To: martin rudalics; +Cc: 14631, lekktu
> Date: Tue, 18 Jun 2013 09:20:41 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: Juanma Barranquero <lekktu@gmail.com>, 14631@debbugs.gnu.org
>
> > This is because we somehow call unblock_input more than we call
> > block_input. Do we have any facilities to find out where this
> > happens? Stefan? anyone?
>
> Add parameters to block_input and unblock_input to remember where they
> were called from. I think that such an investment should pay off in the
> long run.
Would you like to do that, please?
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-06-18 19:32 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-06-16 6:04 bug#14631: 24.3.50; emacs_backtrace.txt Drew Adams
2013-06-16 10:18 ` Juanma Barranquero
2013-06-17 16:33 ` Eli Zaretskii
2013-06-18 7:20 ` martin rudalics
2013-06-18 16:02 ` Eli Zaretskii
2013-06-18 19:32 ` martin rudalics
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
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).