* bug#14936: assertion failure in sysdep.c:emacs_close()
@ 2013-07-23 11:42 Juanma Barranquero
2013-07-25 7:37 ` Paul Eggert
0 siblings, 1 reply; 4+ messages in thread
From: Juanma Barranquero @ 2013-07-23 11:42 UTC (permalink / raw
To: 14936
Package: emacs
Version: 24.3.50
On Windows. Doing nothing weird, just C-c C-c to commit a change to
the bzr repo.
Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 5484.0x4f8]
0x76c7321a in KERNELBASE!DeleteAce () from C:\Windows\syswow64\KernelBase.dll
(gdb) bt
#0 0x76c7321a in KERNELBASE!DeleteAce () from
C:\Windows\syswow64\KernelBase.dll
#1 0x011e96c0 in emacs_abort () at w32fns.c:8030
#2 0x010db4d4 in terminate_due_to_signal (sig=22,
backtrace_limit=2147483647) at emacs.c:369
#3 0x01150655 in die (msg=0x147e8de "errno != EBADF || fd < 0",
file=0x147e766 "sysdep.c", line=2272) at alloc.c:6558
#4 0x010ff953 in emacs_close (fd=4) at sysdep.c:2272
#5 0x0111a0bc in close_file_unwind (fd=4) at fileio.c:220
#6 0x0116e4cc in unbind_to (count=31, value=55406318) at eval.c:3297
#7 0x01122ae4 in Finsert_file_contents (filename=90230017,
visit=54745138, beg=54745114, end=54745114, replace=54745138) at
fileio.c:4585
#8 0x0116d222 in Ffuncall (nargs=6, args=0x88de04) at eval.c:2823
#9 0x011ad6fd in exec_byte_code (bytestr=19487753, vector=19487773,
maxdepth=28, args_template=54745114, nargs=0, args=0x0) at
bytecode.c:905
#10 0x0116dcf4 in funcall_lambda (fun=19487693, nargs=3,
arg_vector=0x1295c1d) at eval.c:3041
#11 0x0116d38a in Ffuncall (nargs=4, args=0x88e100) at eval.c:2856
#12 0x011ad6fd in exec_byte_code (bytestr=85623409, vector=88508885,
maxdepth=28, args_template=2048, nargs=2, args=0x88e400) at
bytecode.c:905
#13 0x0116d930 in funcall_lambda (fun=88508909, nargs=2,
arg_vector=0x88e3f8) at eval.c:2975
#14 0x0116d38a in Ffuncall (nargs=3, args=0x88e3f4) at eval.c:2856
#15 0x011ad6fd in exec_byte_code (bytestr=85623697, vector=88508965,
maxdepth=28, args_template=4100, nargs=4, args=0x88e6fc) at
bytecode.c:905
#16 0x0116d930 in funcall_lambda (fun=88509045, nargs=4,
arg_vector=0x88e6ec) at eval.c:2975
#17 0x0116d38a in Ffuncall (nargs=5, args=0x88e6e8) at eval.c:2856
#18 0x011ad6fd in exec_byte_code (bytestr=85739873, vector=88509117,
maxdepth=40, args_template=4100, nargs=3, args=0x88e9e8) at
bytecode.c:905
#19 0x0116d930 in funcall_lambda (fun=88509149, nargs=3,
arg_vector=0x88e9dc) at eval.c:2975
#20 0x0116d38a in Ffuncall (nargs=4, args=0x88e9d8) at eval.c:2856
#21 0x011ad6fd in exec_byte_code (bytestr=85737089, vector=88509437,
maxdepth=20, args_template=1028, nargs=1, args=0x88ecd0) at
bytecode.c:905
#22 0x0116d930 in funcall_lambda (fun=88509453, nargs=1,
arg_vector=0x88eccc) at eval.c:2975
#23 0x0116d38a in Ffuncall (nargs=2, args=0x88ecc8) at eval.c:2856
#24 0x0116cc39 in call1 (fn=88509453, arg1=85941265) at eval.c:2606
#25 0x011772e2 in mapcar1 (leni=1, vals=0x0, fn=88509453,
seq=85547942) at fns.c:2326
#26 0x01177672 in Fmapc (function=88509453, sequence=85547942) at fns.c:2415
#27 0x0116d174 in Ffuncall (nargs=3, args=0x88ee3c) at eval.c:2810
#28 0x011ad6fd in exec_byte_code (bytestr=85736785, vector=88509477,
maxdepth=40, args_template=1024, nargs=0, args=0x88f154) at
bytecode.c:905
#29 0x0116d930 in funcall_lambda (fun=88509573, nargs=0,
arg_vector=0x88f154) at eval.c:2975
#30 0x0116d38a in Ffuncall (nargs=1, args=0x88f150) at eval.c:2856
#31 0x0116cbb0 in apply1 (fn=85944826, arg=54745114) at eval.c:2573
#32 0x01165ef3 in Fcall_interactively (function=85944826,
record_flag=54745114, keys=54792197) at callint.c:381
#33 0x0116d1a3 in Ffuncall (nargs=2, args=0x88f368) at eval.c:2814
#34 0x011ad6fd in exec_byte_code (bytestr=88950241, vector=83033669,
maxdepth=20, args_template=0, nargs=0, args=0x88f684) at
bytecode.c:905
#35 0x0116d930 in funcall_lambda (fun=86286109, nargs=0,
arg_vector=0x88f684) at eval.c:2975
#36 0x0116d38a in Ffuncall (nargs=1, args=0x88f680) at eval.c:2856
#37 0x0116cbb0 in apply1 (fn=90278986, arg=54745114) at eval.c:2573
#38 0x01165ef3 in Fcall_interactively (function=90278986,
record_flag=54745114, keys=54792197) at callint.c:381
#39 0x0116d1a3 in Ffuncall (nargs=4, args=0x88f88c) at eval.c:2814
#40 0x011ad6fd in exec_byte_code (bytestr=19717201, vector=19717221,
maxdepth=52, args_template=4100, nargs=1, args=0x88fb90) at
bytecode.c:905
#41 0x0116d930 in funcall_lambda (fun=19717181, nargs=1,
arg_vector=0x88fb8c) at eval.c:2975
#42 0x0116d38a in Ffuncall (nargs=2, args=0x88fb88) at eval.c:2856
#43 0x0116cc39 in call1 (fn=54791010, arg1=90278986) at eval.c:2606
#44 0x010df79f in command_loop_1 () at keyboard.c:1560
#45 0x01169fb7 in internal_condition_case (bfun=0x10def79
<command_loop_1>, handlers=54799578, hfun=0x10de800 <cmd_error>) at
eval.c:1293
#46 0x010dec2e in command_loop_2 (ignore=54745114) at keyboard.c:1161
#47 0x01169aa0 in internal_catch (tag=54789458, func=0x10dec0a
<command_loop_2>, arg=54745114) at eval.c:1067
#48 0x010debe6 in command_loop () at keyboard.c:1140
#49 0x010de39d in recursive_edit_1 () at keyboard.c:779
#50 0x010de559 in Frecursive_edit () at keyboard.c:843
#51 0x010dc827 in main (argc=3, argv=0x9b2ff8) at emacs.c:1566
Lisp Backtrace:
"insert-file-contents" (0x88de08)
"revert-buffer" (0x88e104)
"vc-revert-buffer-internal" (0x88e3f8)
"vc-resynch-window" (0x88e6ec)
"vc-resynch-buffer" (0x88e9dc)
0x5468c08 PVEC_COMPILED
"mapc" (0x88ee40)
"vc-finish-logentry" (0x88f154)
"call-interactively" (0x88f36c)
"log-edit-done" (0x88f684)
"call-interactively" (0x88f890)
"command-execute" (0x88fb8c)
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#14936: assertion failure in sysdep.c:emacs_close()
2013-07-23 11:42 bug#14936: assertion failure in sysdep.c:emacs_close() Juanma Barranquero
@ 2013-07-25 7:37 ` Paul Eggert
2013-07-25 7:41 ` Juanma Barranquero
2013-07-25 8:10 ` Paul Eggert
0 siblings, 2 replies; 4+ messages in thread
From: Paul Eggert @ 2013-07-25 7:37 UTC (permalink / raw
To: Juanma Barranquero; +Cc: 14936
Thanks, that's what appears to be a longstanding double-close
race in Emacs, caught by a recently-introduced eassert that
tries to stomp out this sort of thing. I installed what I hope
is a fix in trunk bzr 113538; please give it a try.
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#14936: assertion failure in sysdep.c:emacs_close()
2013-07-25 7:37 ` Paul Eggert
@ 2013-07-25 7:41 ` Juanma Barranquero
2013-07-25 8:10 ` Paul Eggert
1 sibling, 0 replies; 4+ messages in thread
From: Juanma Barranquero @ 2013-07-25 7:41 UTC (permalink / raw
To: Paul Eggert; +Cc: 14936-done
> Thanks, that's what appears to be a longstanding double-close
> race in Emacs, caught by a recently-introduced eassert that
> tries to stomp out this sort of thing. I installed what I hope
> is a fix in trunk bzr 113538; please give it a try.
I have no recipe, so I cannot test specifically that it works. I'm
closing this bug. Will reopen if it happens again.
Thanks,
J
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#14936: assertion failure in sysdep.c:emacs_close()
2013-07-25 7:37 ` Paul Eggert
2013-07-25 7:41 ` Juanma Barranquero
@ 2013-07-25 8:10 ` Paul Eggert
1 sibling, 0 replies; 4+ messages in thread
From: Paul Eggert @ 2013-07-25 8:10 UTC (permalink / raw
To: Juanma Barranquero; +Cc: 14936
Hmm, on further thought the bug is not a longstanding one,
it's one I introduced a couple of weeks ago. I installed
a more-conservative fix.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-07-25 8:10 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-07-23 11:42 bug#14936: assertion failure in sysdep.c:emacs_close() Juanma Barranquero
2013-07-25 7:37 ` Paul Eggert
2013-07-25 7:41 ` Juanma Barranquero
2013-07-25 8:10 ` Paul Eggert
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.