* bug#12839: 24.3.50; Emacs aborts in GC
@ 2012-11-08 17:12 Eli Zaretskii
2012-11-08 22:05 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2012-11-08 17:12 UTC (permalink / raw
To: 12839, dmantipov
This bug report will be sent to the Bug-GNU-Emacs mailing list
and the GNU bug tracker at debbugs.gnu.org. Please check that
the From: line contains a valid email address. After a delay of up
to one day, you should receive an acknowledgement at that address.
Please write in English if possible, as the Emacs maintainers
usually do not have translators for other languages.
Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug. If you can, give a recipe
starting from `emacs -Q':
(This is being sent from Emacs 24.2, since the trunk is unusable, see
below. So please take the data reported by report-emacs-bug with a
grain of salt.)
With the current trunk, the first GC in the "emacs -Q" session aborts.
It doesn't matter what triggers the GC. The backtrace is below. Let
me know if I can help finding the problem.
#1 0x01233dad in emacs_abort () at w32fns.c:7766
#2 0x0100139c in terminate_due_to_signal (sig=22, backtrace_limit=2147483647)
at emacs.c:345
#3 0x01021d64 in die (
msg=0x154362c "assertion failed: (tmp) < VECTOR_MAX_FREE_LIST_INDEX",
file=0x1542dd1 "alloc.c", line=2864) at alloc.c:6483
#4 0x0101b1a8 in sweep_vectors () at alloc.c:2864
#5 0x01021a05 in gc_sweep () at alloc.c:6376
#6 0x0101f320 in Fgarbage_collect () at alloc.c:5321
#7 0x01018387 in maybe_gc () at lisp.h:3676
#8 0x01012c68 in eval_sub (form=59772478) at eval.c:2036
#9 0x0104ac36 in readevalloop (readcharfun=55932954, stream=0x77c5fd00,
sourcename=55930433, printflag=false, unibyte=55855130, readfun=55855130,
start=55855130, end=55855130) at lread.c:1842
#10 0x01048cc6 in Fload (file=56888641, noerror=55855130, nomessage=55855154,
nosuffix=55855130, must_suffix=55855154) at lread.c:1315
#11 0x0103f093 in Frequire (feature=55922650, filename=55855130,
noerror=55855130) at fns.c:2651
#12 0x01015248 in Ffuncall (nargs=2, args=0x82dc44) at eval.c:2781
#13 0x011254bf in exec_byte_code (bytestr=56888481, vector=59632877,
maxdepth=16, args_template=55855130, nargs=0, args=0x0) at bytecode.c:899
#14 0x01124932 in Fbyte_code (bytestr=56888481, vector=59632877, maxdepth=16)
at bytecode.c:474
#15 0x0101355a in eval_sub (form=59009206) at eval.c:2145
#16 0x0104ac36 in readevalloop (readcharfun=55932954, stream=0x77c5fce0,
sourcename=56886145, printflag=false, unibyte=55855130, readfun=55855130,
start=55855130, end=55855130) at lread.c:1842
#17 0x01048cc6 in Fload (file=20525321, noerror=55855130, nomessage=55855154,
nosuffix=55855130, must_suffix=55855154) at lread.c:1315
#18 0x010129bf in Fautoload_do_load (fundef=20525366, funname=57611794,
macro_only=55855130) at eval.c:1973
#19 0x0101566e in Ffuncall (nargs=1, args=0x82e624) at eval.c:2838
#20 0x011254bf in exec_byte_code (bytestr=20395169, vector=20395213,
maxdepth=12, args_template=55855130, nargs=0, args=0x0) at bytecode.c:899
#21 0x01016097 in funcall_lambda (fun=20395141, nargs=2, arg_vector=0x82e878)
at eval.c:3006
#22 0x0101556f in Ffuncall (nargs=3, args=0x82e874) at eval.c:2823
#23 0x011254bf in exec_byte_code (bytestr=20394193, vector=20394453,
maxdepth=24, args_template=55855130, nargs=0, args=0x0) at bytecode.c:899
#24 0x01016097 in funcall_lambda (fun=20394157, nargs=0, arg_vector=0x82ea40)
at eval.c:3006
#25 0x010158a7 in apply_lambda (fun=20394157, args=55855130) at eval.c:2883
#26 0x0101387c in eval_sub (form=20388694) at eval.c:2184
#27 0x01010f11 in internal_lisp_condition_case (var=57691882,
bodyform=20388694, handlers=20388702) at eval.c:1242
#28 0x01125f3e in exec_byte_code (bytestr=20388513, vector=20388613,
maxdepth=16, args_template=55855130, nargs=0, args=0x0) at bytecode.c:1095
#29 0x01016097 in funcall_lambda (fun=20388469, nargs=1, arg_vector=0x82ef28)
at eval.c:3006
#30 0x0101556f in Ffuncall (nargs=2, args=0x82ef24) at eval.c:2823
#31 0x011254bf in exec_byte_code (bytestr=20387521, vector=20387789,
maxdepth=20, args_template=55855130, nargs=0, args=0x0) at bytecode.c:899
#32 0x01016097 in funcall_lambda (fun=20387453, nargs=2, arg_vector=0x82f188)
at eval.c:3006
#33 0x0101556f in Ffuncall (nargs=3, args=0x82f184) at eval.c:2823
#34 0x011254bf in exec_byte_code (bytestr=20385409, vector=20385581,
maxdepth=12, args_template=55855130, nargs=0, args=0x0) at bytecode.c:899
#35 0x01016097 in funcall_lambda (fun=20385341, nargs=6, arg_vector=0x82f3d8)
at eval.c:3006
#36 0x0101556f in Ffuncall (nargs=7, args=0x82f3d4) at eval.c:2823
#37 0x011254bf in exec_byte_code (bytestr=20384209, vector=20384573,
maxdepth=32, args_template=55855130, nargs=0, args=0x0) at bytecode.c:899
#38 0x01016097 in funcall_lambda (fun=20384157, nargs=4, arg_vector=0x82f648)
at eval.c:3006
#39 0x0101556f in Ffuncall (nargs=5, args=0x82f644) at eval.c:2823
#40 0x011254bf in exec_byte_code (bytestr=20379313, vector=20379365,
maxdepth=24, args_template=55855130, nargs=0, args=0x0) at bytecode.c:899
#41 0x01016097 in funcall_lambda (fun=20379261, nargs=2, arg_vector=0x82f8a4)
at eval.c:3006
#42 0x0101556f in Ffuncall (nargs=3, args=0x82f8a0) at eval.c:2823
#43 0x01014360 in Fapply (nargs=2, args=0x82f940) at eval.c:2308
#44 0x010148e4 in apply1 (fn=57591626, arg=59777350) at eval.c:2542
#45 0x011226fe in Fcall_interactively (function=57591626,
record_flag=55855130, keys=55876469) at callint.c:377
#46 0x01015248 in Ffuncall (nargs=4, args=0x82fb80) at eval.c:2781
#47 0x010149b9 in call3 (fn=55972634, arg1=57591626, arg2=55855130,
arg3=55855130) at eval.c:2599
#48 0x010acf89 in Fcommand_execute (cmd=57591626, record_flag=55855130,
keys=55855130, special=55855130) at keyboard.c:10240
#49 0x010935ca in command_loop_1 () at keyboard.c:1586
#50 0x0101101b in internal_condition_case (bfun=0x1092870 <command_loop_1>,
handlers=55905738, hfun=0x10920b0 <cmd_error>) at eval.c:1288
#51 0x010924fc in command_loop_2 (ignore=55855130) at keyboard.c:1167
#52 0x01010a23 in internal_catch (tag=55895594,
func=0x10924d9 <command_loop_2>, arg=55855130) at eval.c:1059
#53 0x010924b4 in command_loop () at keyboard.c:1146
#54 0x01091a81 in recursive_edit_1 () at keyboard.c:778
#55 0x01091da3 in Frecursive_edit () at keyboard.c:842
#56 0x01002863 in main (argc=2, argv=0xa43f90) at emacs.c:1564
Lisp Backtrace:
"Automatic GC" (0x166e620)
"require" (0x82dc48)
"byte-code" (0x82de20)
"c-mode" (0x82e628)
"set-auto-mode-0" (0x82e878)
"set-auto-mode" (0x82ea40)
"normal-mode" (0x82ef28)
"after-find-file" (0x82f188)
"find-file-noselect-1" (0x82f3d8)
"find-file-noselect" (0x82f648)
"find-file" (0x82f8a4)
"call-interactively" (0x82fb84)
(gdb)
If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
`bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
d:/usr/emacs/etc/DEBUG.
In GNU Emacs 24.2.1 (i386-mingw-nt5.1.2600)
of 2012-09-17 on HOME-C4E4A596F7
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
`configure --with-gcc (3.4)'
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: ENU
value of $XMODIFIERS: nil
locale-coding-system: cp1255
default enable-multibyte-characters: t
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
M-x r e p o r t - e m a c s - b u g <return>
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Load-path shadows:
None found.
Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail regexp-opt rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils time-date tooltip ediff-hook
vc-hooks lisp-float-type mwheel dos-w32 disp-table ls-lisp w32-win
w32-vars tool-bar dnd fontset image fringe lisp-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs
button faces cus-face files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process multi-tty emacs)
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12839: 24.3.50; Emacs aborts in GC
2012-11-08 17:12 bug#12839: 24.3.50; Emacs aborts in GC Eli Zaretskii
@ 2012-11-08 22:05 ` Eli Zaretskii
2012-11-09 3:40 ` Dmitry Antipov
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2012-11-08 22:05 UTC (permalink / raw
To: dmantipov; +Cc: 12839
> Date: Thu, 08 Nov 2012 19:12:19 +0200
> From: Eli Zaretskii <eliz@gnu.org>
>
> With the current trunk, the first GC in the "emacs -Q" session aborts.
> It doesn't matter what triggers the GC. The backtrace is below. Let
> me know if I can help finding the problem.
>
> #1 0x01233dad in emacs_abort () at w32fns.c:7766
> #2 0x0100139c in terminate_due_to_signal (sig=22, backtrace_limit=2147483647)
> at emacs.c:345
> #3 0x01021d64 in die (
> msg=0x154362c "assertion failed: (tmp) < VECTOR_MAX_FREE_LIST_INDEX",
> file=0x1542dd1 "alloc.c", line=2864) at alloc.c:6483
> #4 0x0101b1a8 in sweep_vectors () at alloc.c:2864
Looks like I'm talking to myself here, but on the faint hope that
someone does or will read this, here's some data:
(gdb) r -Q
Starting program: D:\gnu\bzr\emacs\trunk\src\oo\i386\emacs.exe -Q
[New Thread 7964.0x1eac]
[New Thread 7964.0x1c24]
[New Thread 7964.0xdf0]
alloc.c:2864: Emacs fatal error: assertion failed: (tmp) < VECTOR_MAX_FREE_LIST_INDEX
Breakpoint 1, terminate_due_to_signal (sig=22, backtrace_limit=2147483647)
at emacs.c:318
318 signal (sig, SIG_DFL);
(gdb) up
#1 0x01021d64 in die (
msg=0x154362c "assertion failed: (tmp) < VECTOR_MAX_FREE_LIST_INDEX",
file=0x1542dd1 "alloc.c", line=2864) at alloc.c:6483
6483 terminate_due_to_signal (SIGABRT, INT_MAX);
(gdb) up
#2 0x0101b1a8 in sweep_vectors () at alloc.c:2864
2864 SETUP_ON_FREE_LIST (vector, total_bytes, tmp);
(gdb) l
2859 space was coalesced into the only free vector. */
2860 free_this_block = 1;
2861 else
2862 {
2863 int tmp;
2864 SETUP_ON_FREE_LIST (vector, total_bytes, tmp);
2865 }
2866 }
2867 }
2868
(gdb) p total_bytes
$1 = 223420624
(gdb) p vector->header_size
There is no member named header_size.
(gdb) p vector->header.size
$2 = 1166225408
(gdb) p vector->header
$3 = {
size = 1166225408
}
Looks like this vector is complete garbage. And the same goes for the
first one on vector_blocks:
(gdb) p (struct Lisp_Vector *)vector_blocks->data
$5 = (struct Lisp_Vector *) 0x357e000
(gdb) p ((struct Lisp_Vector *)vector_blocks->data)->header
$6 = {
size = 1275068420
}
Also, a different, but related, crash:
emacs -Q
C-x 3
M-x set-variable RET auto-hscroll-mode RET nil RET
This yields the following crash:
Program received signal SIGSEGV, Segmentation fault.
0x010201e5 in mark_object (arg=1325400077) at alloc.c:5722
5722 if (VECTOR_MARKED_P (ptr))
(gdb) l
5717 case Lisp_Vectorlike:
5718 {
5719 register struct Lisp_Vector *ptr = XVECTOR (obj);
5720 register ptrdiff_t pvectype;
5721
5722 if (VECTOR_MARKED_P (ptr))
5723 break;
5724
5725 #ifdef GC_CHECK_MARKED_OBJECTS
5726 m = mem_find (po);
(gdb) p ptr
$1 = (struct Lisp_Vector *) 0x4f000008
(gdb) p *ptr
Cannot access memory at address 0x4f000008
I hope this will make sense to someone.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12839: 24.3.50; Emacs aborts in GC
2012-11-08 22:05 ` Eli Zaretskii
@ 2012-11-09 3:40 ` Dmitry Antipov
2012-11-09 7:24 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Dmitry Antipov @ 2012-11-09 3:40 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 12839
On 11/09/2012 02:05 AM, Eli Zaretskii wrote:
> Looks like I'm talking to myself here
No.
Although I do my best to avoid platform-dependent tricks, some
things are platform-dependent anyway, like the DEFUN macro. If you
compile with Microsoft compiler, this is your case; can you use
gdb to dump any struct Lisp_Subr to see it's vectorlike_header?
Also, if you suspect potentially bogus struct Lisp_Vector pointers,
please try xvectype and xvecsize gdb commands to get something
more informative than just the header->size shown as integer.
> Also, a different, but related, crash:
>
> emacs -Q
> C-x 3
> M-x set-variable RET auto-hscroll-mode RET nil RET
I can't reproduce it on Linux, so it looks like the same
platform-dependent problem.
Dmitry
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12839: 24.3.50; Emacs aborts in GC
2012-11-09 3:40 ` Dmitry Antipov
@ 2012-11-09 7:24 ` Eli Zaretskii
2012-11-09 8:56 ` Eli Zaretskii
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Eli Zaretskii @ 2012-11-09 7:24 UTC (permalink / raw
To: Dmitry Antipov; +Cc: 12839
> Date: Fri, 09 Nov 2012 07:40:10 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: 12839@debbugs.gnu.org
>
> Although I do my best to avoid platform-dependent tricks, some
> things are platform-dependent anyway, like the DEFUN macro. If you
> compile with Microsoft compiler, this is your case;
I'm using GCC, not the Microsoft compiler. The MinGW development
environment uses ported GNU utilities (GCC, Binutils, GDB, etc.) to
compile native Windows programs. (If I were using MSVC, I couldn't
have debugged programs with GDB, because GDB doesn't support the PDB
debug info format emitted by the Microsoft compiler.)
> can you use
> gdb to dump any struct Lisp_Subr to see it's vectorlike_header?
Is this what you wanted:
(gdb) p Scons
$6 = {
header = {
size = 1241513984
},
function = {
a0 = 0x101a52e <Fcons>,
a1 = 0x101a52e <Fcons>,
a2 = 0x101a52e <Fcons>,
a3 = 0x101a52e <Fcons>,
a4 = 0x101a52e <Fcons>,
a5 = 0x101a52e <Fcons>,
a6 = 0x101a52e <Fcons>,
a7 = 0x101a52e <Fcons>,
a8 = 0x101a52e <Fcons>,
aUNEVALLED = 0x101a52e <Fcons>,
aMANY = 0x101a52e <Fcons>
},
min_args = 2,
max_args = 2,
symbol_name = 0x1543375 "cons",
intspec = 0x0,
doc = 0xfff9849c <Address 0xfff9849c out of bounds>
}
(gdb) p *(struct vectorlike_header *)&(Scons.header)
$7 = {
size = 1241513984
}
(gdb) p/x *(struct vectorlike_header *)&(Scons.header)
$8 = {
size = 0x4a000000
}
> Also, if you suspect potentially bogus struct Lisp_Vector pointers,
> please try xvectype and xvecsize gdb commands to get something
> more informative than just the header->size shown as integer.
Sorry, I'm not sure I understand: in the first backtrace I've shown,
which was here (alloc.c:sweep_vectors):
else
{
int tmp;
SETUP_ON_FREE_LIST (vector, total_bytes, tmp); <<<<<<<
}
the vector in question is not a Lisp object, it is a pointer to
'struct Lisp_Vector':
#2 0x0101b1a8 in sweep_vectors () at alloc.c:2864
2864 SETUP_ON_FREE_LIST (vector, total_bytes, tmp);
(gdb) p vector
$1 = (struct Lisp_Vector *) 0x38ae230
Maybe you meant this:
(gdb) p *vector
$2 = {
header = {
size = 1166225408
},
contents = {55859226}
}
(gdb) p vector->contents
$3 = {55859226}
(gdb) p vector->contents[0]
$4 = 55859226
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$5 = (struct Lisp_Symbol *) 0x3545818
"nil"
> > emacs -Q
> > C-x 3
> > M-x set-variable RET auto-hscroll-mode RET nil RET
>
> I can't reproduce it on Linux, so it looks like the same
> platform-dependent problem.
I'd be happy to try debugging this myself, but I need guidance
regarding some basics of what you changed recently in this area.
Alternatively, tell me what to do in GDB, and I will post the results.
I'm quite fluent with GDB, and reproducing this is extremely easy :-(.
TIA
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12839: 24.3.50; Emacs aborts in GC
2012-11-09 7:24 ` Eli Zaretskii
@ 2012-11-09 8:56 ` Eli Zaretskii
2012-11-09 12:44 ` Dmitry Antipov
2012-11-09 13:17 ` Dmitry Antipov
2 siblings, 0 replies; 12+ messages in thread
From: Eli Zaretskii @ 2012-11-09 8:56 UTC (permalink / raw
To: dmantipov; +Cc: 12839
Btw, curiously, it never crashes during dumping nor when compiling
Lisp files, although both GC and vectors are used during these. So
this sounds like it's related to something that is only used during
interactive sessions.
As another data point, I tried debugging temacs and got this:
(gdb) r -Q
Starting program: D:\gnu\bzr\emacs\trunk\src\oo\i386\temacs.exe -Q
[New Thread 8180.0x1678]
[New Thread 8180.0x1820]
Loading loadup.el (source)...
Using load-path (../lisp)
Loading emacs-lisp/byte-run...
Loading emacs-lisp/byte-run...done
Loading emacs-lisp/backquote...
Loading emacs-lisp/backquote...done
Loading subr...
Loading subr...done
[... rest of loading omitted ...]
Loading tooltip...
Loading tooltip...done
Finding pointers to doc strings...
Finding pointers to doc strings...done
Pure-hashed: 22172 strings, 3127 vectors, 36397 conses, 2832 bytecodes, 85 others
[New Thread 8180.0x15d4]
Program received signal SIGSEGV, Segmentation fault.
0x01130f12 in print_object (obj=38, printcharfun=55859250, escapeflag=1)
at print.c:1669
1669 print_object (XCAR (obj), printcharfun, escapeflag);
(gdb) l
1664 strout ("...", 3, 3, printcharfun);
1665 goto end_of_list;
1666 }
1667
1668 i++;
1669 print_object (XCAR (obj), printcharfun, escapeflag);
1670
1671 obj = XCDR (obj);
1672 if (!(i & 1))
1673 halftail = XCDR (halftail);
(gdb) info threads
Id Target Id Frame
3 Thread 8180.0x15d4 0x7c90e514 in ntdll!LdrAccessResource ()
from C:\WINDOWS\system32\ntdll.dll
2 Thread 8180.0x1820 0x7c90e514 in ntdll!LdrAccessResource ()
from C:\WINDOWS\system32\ntdll.dll
* 1 Thread 8180.0x1678 0x01130f12 in print_object (obj=38,
printcharfun=55859250, escapeflag=1) at print.c:1669
(gdb) bt
#0 0x01130f12 in print_object (obj=38, printcharfun=55859250, escapeflag=1)
at print.c:1669
#1 0x01132796 in print_object (obj=60452533, printcharfun=55859250,
escapeflag=1) at print.c:1985
#2 0x0112e1d1 in print (obj=60452533, printcharfun=55859250, escapeflag=1)
at print.c:1103
#3 0x0112b93b in Fprin1 (object=60452533, printcharfun=55859250)
at print.c:560
#4 0x0112dc11 in print_error_message (data=60626454, stream=55859250,
context=0x82fcb0 "", caller=58331306) at print.c:915
#5 0x0109252f in cmd_error_internal (data=60626454, context=0x82fcb0 "")
at keyboard.c:1118
#6 0x010922b0 in cmd_error (data=60626454) at keyboard.c:1054
#7 0x01010fc5 in internal_condition_case (bfun=0x1092980 <command_loop_1>,
handlers=55909570, hfun=0x10921c0 <cmd_error>) at eval.c:1278
#8 0x0109260c in command_loop_2 (ignore=55859226) at keyboard.c:1167
#9 0x01010a23 in internal_catch (tag=55899426,
func=0x10925e9 <command_loop_2>, arg=55859226) at eval.c:1059
#10 0x010925c4 in command_loop () at keyboard.c:1146
#11 0x01091b91 in recursive_edit_1 () at keyboard.c:778
#12 0x01091eb3 in Frecursive_edit () at keyboard.c:842
#13 0x01002863 in main (argc=2, argv=0xa427c8) at emacs.c:1564
(gdb) frame 6
#6 0x010922b0 in cmd_error (data=60626454) at keyboard.c:1054
1054 cmd_error_internal (data, macroerror);
(gdb) pp data
(wrong-type-argument window-configuration-p [#<frame temacs@HOME-C4E4A596F7 03847E70> #<window 3 on *scratch*> #<buffer *scratch*> nil nil #<window 3 on *scratch*> nil [[#<window 3 on *scratch*> #<buffer *scratch*> #<marker at 1 in *scratch*> #<marker at 192 in *scratch*> #<marker in no buffer> 0 3 84 34 1.0 ...] [#<window 4 on *Minibuf-1*> #<buffer *Minibuf-0*> #<marker at 1 in *Echo Area 1*> #<marker at 1 in *Minibuf-0*> #<marker in no buffer> 0 37 84 1 1.0 ...]] 20 (
Program received signal SIGSEGV, Segmentation fault.
0x01130f12 in print_object (obj=38, printcharfun=55978898, escapeflag=1)
at print.c:1669
1669 print_object (XCAR (obj), printcharfun, escapeflag);
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(safe_debug_print) will be abandoned.
When the function is done executing, GDB will silently stop.
(The SIGSEGV caused by 'pp' was expected, but it produces the contents
of the error object much more easily, so it was worth the risk.)
This looks like Emacs was signaling an error because some variable
that was supposed to be a window configuration wasn't, or some window
stored in that configuration wasn't a valid window object.
HTH
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12839: 24.3.50; Emacs aborts in GC
2012-11-09 7:24 ` Eli Zaretskii
2012-11-09 8:56 ` Eli Zaretskii
@ 2012-11-09 12:44 ` Dmitry Antipov
2012-11-09 14:47 ` Eli Zaretskii
2012-11-09 13:17 ` Dmitry Antipov
2 siblings, 1 reply; 12+ messages in thread
From: Dmitry Antipov @ 2012-11-09 12:44 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 12839
On 11/09/2012 11:24 AM, Eli Zaretskii wrote:
> Is this what you wanted:
>
> (gdb) p Scons
> $6 = {
> header = {
> size = 1241513984
> },
Yes. The header looks to be valid here
((1241513984 & (0x3f << 24)) >> 24 is 10, e.g. PVEC_SUBR).
> Sorry, I'm not sure I understand: in the first backtrace I've shown,
> which was here (alloc.c:sweep_vectors):
>
> else
> {
> int tmp;
> SETUP_ON_FREE_LIST (vector, total_bytes, tmp); <<<<<<<
> }
>
> the vector in question is not a Lisp object, it is a pointer to
> 'struct Lisp_Vector':
I just committed r110854 with pvectype and pvecsize commands, similar
to xvectype and xvecsize; now it should be possible to do something like:
(gdb) p current_buffer
$1 = (struct buffer *) 0xd40ad0
(gdb) pvectype current_buffer
PVEC_BUFFER
(gdb) pvecsize current_buffer
69
48
(gdb) p selected_frame
$2 = {
i = 19612573
}
(gdb) xvectype
PVEC_FRAME
(gdb) xvecsize
22
47
(gdb)
So, if you see the potentially bogus struct Lisp_Vector pointer, try
pvectype and pvecsize; if you see a bogus Lisp_Object of Lisp_Vectorlike
type, try xvectype and xvecsize.
> I'd be happy to try debugging this myself, but I need guidance
> regarding some basics of what you changed recently in this area.
The goal was to shrink struct vectorlike_header to the only 'size'
field (which is totally overloaded and has the totally misleading
name; someday I would like to switch to bitfields). This means
that we should know the memory footprint of any vectorlike object.
For the regular vector V, the memory footprint is:
header_size + V->header.size * word_size
This is simple because V->header.size is interpreted as follows
(assuming 32-bit code):
31 0
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
mpssssssssssssssssssssssssssssss
|||
||| - s) size bits
|| - p)seudovector bit (always 0)
|- m)ark bit
For the pseudovector V, the layout is:
31 0
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
mpssssssrrrrrrrrrrrrllllllllllll
||| | |
||| | | l)isp area size, in Lisp_Objects (12 bits) (L)
||| | r)est area size, in word_size units (12 bits) (R)
||| - s)ubtype (PVEC_xxx, 6 bits)
||- p)seudovector bit (always 1)
|- m)ark bit
(This layout is documented around enum More_Lisp_Bits and
struct vectorlike_header in lisp.h).
So, for the pseudovector V, the memory footprint is:
header_size + (R + L) * word_size
Function vector_nbytes in alloc.c works almost like described
above (with an exception of Lisp_Bool_Vector).
That's why 'pvecsize current_buffer' GDB command prints two numbers.
On a 64-bit system, there are:
(gdb) pvecsize current_buffer
69
48
(gdb)
These are L and R fields, respectively. Since word_size is 8,
header_size + (L + R) * word_size is 8 + (69 + 48) * 8 = 944,
which is equal to sizeof (struct buffer).
The rule above applies to all pseudovector objects except
PVEC_SUBR and PVEC_FREE (but remember that size is rounded up
to multiple of 8 on 32-bit platforms); if it isn't, this is
a bug which is very likely to cause crash with memory corruption
or bogus vector pointers.
Dmitry
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12839: 24.3.50; Emacs aborts in GC
2012-11-09 7:24 ` Eli Zaretskii
2012-11-09 8:56 ` Eli Zaretskii
2012-11-09 12:44 ` Dmitry Antipov
@ 2012-11-09 13:17 ` Dmitry Antipov
2012-11-09 13:27 ` Dmitry Antipov
2012-11-09 14:16 ` Eli Zaretskii
2 siblings, 2 replies; 12+ messages in thread
From: Dmitry Antipov @ 2012-11-09 13:17 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 12839
On 11/09/2012 11:24 AM, Eli Zaretskii wrote:
> I'd be happy to try debugging this myself, but I need guidance
> regarding some basics of what you changed recently in this area.
> Alternatively, tell me what to do in GDB, and I will post the results.
> I'm quite fluent with GDB, and reproducing this is extremely easy :-(.
Try this:
=== modified file 'src/w32term.h'
--- src/w32term.h 2012-10-17 19:02:44 +0000
+++ src/w32term.h 2012-11-09 13:13:43 +0000
@@ -414,10 +414,8 @@
vector. */
struct scroll_bar {
-
- /* These fields are shared by all vectors. */
- EMACS_INT size_from_Lisp_Vector_struct;
- struct Lisp_Vector *next_from_Lisp_Vector_struct;
+ /* This field is shared by all vectors. */
+ struct vectorlike_header header;
/* The window we're a scroll bar for. */
Lisp_Object window;
This is Windows-specific and obviously wrong since sizeof (struct vectorlike_header)
is now _less than_ sizeof (EMACS_INT) + sizeof (struct Lisp_Vector *).
Dmitry
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12839: 24.3.50; Emacs aborts in GC
2012-11-09 13:17 ` Dmitry Antipov
@ 2012-11-09 13:27 ` Dmitry Antipov
2012-11-09 14:16 ` Eli Zaretskii
1 sibling, 0 replies; 12+ messages in thread
From: Dmitry Antipov @ 2012-11-09 13:27 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 12839
On 11/09/2012 05:17 PM, Dmitry Antipov wrote:
> On 11/09/2012 11:24 AM, Eli Zaretskii wrote:
>
>> I'd be happy to try debugging this myself, but I need guidance
>> regarding some basics of what you changed recently in this area.
>> Alternatively, tell me what to do in GDB, and I will post the results.
>> I'm quite fluent with GDB, and reproducing this is extremely easy :-(.
>
> Try this:
And this, too:
=== modified file 'src/w32term.c'
--- src/w32term.c 2012-10-08 13:46:03 +0000
+++ src/w32term.c 2012-11-09 13:25:41 +0000
@@ -3626,7 +3626,7 @@
HWND hwnd;
SCROLLINFO si;
struct scroll_bar *bar
- = XSCROLL_BAR (Fmake_vector (make_number (SCROLL_BAR_VEC_SIZE), Qnil));
+ = XSCROLL_BAR (Fmake_vector (make_number (VECSIZE (struct scroll_bar))), Qnil);
Lisp_Object barobj;
block_input ();
=== modified file 'src/w32term.h'
--- src/w32term.h 2012-10-17 19:02:44 +0000
+++ src/w32term.h 2012-11-09 13:25:39 +0000
@@ -460,12 +460,6 @@
Lisp_Object fringe_extended_p;
};
-/* The number of elements a vector holding a struct scroll_bar needs. */
-#define SCROLL_BAR_VEC_SIZE \
- ((sizeof (struct scroll_bar) \
- - sizeof (EMACS_INT) - sizeof (struct Lisp_Vector *)) \
- / word_size)
-
/* Turning a lisp vector value into a pointer to a struct scroll_bar. */
#define XSCROLL_BAR(vec) ((struct scroll_bar *) XVECTOR (vec))
Dmitry
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12839: 24.3.50; Emacs aborts in GC
2012-11-09 13:17 ` Dmitry Antipov
2012-11-09 13:27 ` Dmitry Antipov
@ 2012-11-09 14:16 ` Eli Zaretskii
2012-11-09 14:46 ` Dmitry Antipov
1 sibling, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2012-11-09 14:16 UTC (permalink / raw
To: Dmitry Antipov; +Cc: 12839
> Date: Fri, 09 Nov 2012 17:17:26 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: 12839@debbugs.gnu.org
>
> On 11/09/2012 11:24 AM, Eli Zaretskii wrote:
>
> > I'd be happy to try debugging this myself, but I need guidance
> > regarding some basics of what you changed recently in this area.
> > Alternatively, tell me what to do in GDB, and I will post the results.
> > I'm quite fluent with GDB, and reproducing this is extremely easy :-(.
>
> Try this:
>
> === modified file 'src/w32term.h'
> --- src/w32term.h 2012-10-17 19:02:44 +0000
> +++ src/w32term.h 2012-11-09 13:13:43 +0000
> @@ -414,10 +414,8 @@
> vector. */
>
> struct scroll_bar {
> -
> - /* These fields are shared by all vectors. */
> - EMACS_INT size_from_Lisp_Vector_struct;
> - struct Lisp_Vector *next_from_Lisp_Vector_struct;
> + /* This field is shared by all vectors. */
> + struct vectorlike_header header;
>
> /* The window we're a scroll bar for. */
> Lisp_Object window;
I applied this together with the other patch you sent, and the 2
crashes I saw earlier do not happen anymore. Thanks.
> This is Windows-specific and obviously wrong since sizeof (struct vectorlike_header)
> is now _less than_ sizeof (EMACS_INT) + sizeof (struct Lisp_Vector *).
If it's wrong, why use it? What would be the right change?
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12839: 24.3.50; Emacs aborts in GC
2012-11-09 14:16 ` Eli Zaretskii
@ 2012-11-09 14:46 ` Dmitry Antipov
2012-11-09 14:53 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Dmitry Antipov @ 2012-11-09 14:46 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 12839
On 11/09/2012 06:16 PM, Eli Zaretskii wrote:
> I applied this together with the other patch you sent, and the 2
> crashes I saw earlier do not happen anymore. Thanks.
Good news.
>> This is Windows-specific and obviously wrong since sizeof (struct vectorlike_header)
>> is now _less than_ sizeof (EMACS_INT) + sizeof (struct Lisp_Vector *).
>
> If it's wrong, why use it? What would be the right change?
Heh, sorry, I mean that current code (not my patch) is wrong :-( and
so w32 scroll bar should use the convenient struct vectorlike_header.
Installed as r110855.
Dmitry
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12839: 24.3.50; Emacs aborts in GC
2012-11-09 12:44 ` Dmitry Antipov
@ 2012-11-09 14:47 ` Eli Zaretskii
0 siblings, 0 replies; 12+ messages in thread
From: Eli Zaretskii @ 2012-11-09 14:47 UTC (permalink / raw
To: Dmitry Antipov; +Cc: 12839
> Date: Fri, 09 Nov 2012 16:44:26 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: 12839@debbugs.gnu.org
>
> (gdb) pvectype current_buffer
> PVEC_BUFFER
> (gdb) pvecsize current_buffer
> 69
> 48
I get different results here:
(gdb) pvectype current_buffer
PVEC_BUFFER
(gdb) pvecsize current_buffer
69
55
(gdb) p selected_frame
$2 = 55923965
(gdb) xvectype
PVEC_FRAME
(gdb) xvecsize
22
73
How to know whether the results of these commands are correct?
> (This layout is documented around enum More_Lisp_Bits and
> struct vectorlike_header in lisp.h).
Maybe I'm blind, but I don't see anything that's near this detailed
description. How about just making a large comment with all this
text?
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12839: 24.3.50; Emacs aborts in GC
2012-11-09 14:46 ` Dmitry Antipov
@ 2012-11-09 14:53 ` Eli Zaretskii
0 siblings, 0 replies; 12+ messages in thread
From: Eli Zaretskii @ 2012-11-09 14:53 UTC (permalink / raw
To: Dmitry Antipov; +Cc: 12839
> Date: Fri, 09 Nov 2012 18:46:39 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: 12839@debbugs.gnu.org
>
> On 11/09/2012 06:16 PM, Eli Zaretskii wrote:
>
> > I applied this together with the other patch you sent, and the 2
> > crashes I saw earlier do not happen anymore. Thanks.
>
> Good news.
>
> >> This is Windows-specific and obviously wrong since sizeof (struct vectorlike_header)
> >> is now _less than_ sizeof (EMACS_INT) + sizeof (struct Lisp_Vector *).
> >
> > If it's wrong, why use it? What would be the right change?
>
> Heh, sorry, I mean that current code (not my patch) is wrong :-( and
> so w32 scroll bar should use the convenient struct vectorlike_header.
>
> Installed as r110855.
Thanks. I think the bug can be closed now.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2012-11-09 14:53 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-11-08 17:12 bug#12839: 24.3.50; Emacs aborts in GC Eli Zaretskii
2012-11-08 22:05 ` Eli Zaretskii
2012-11-09 3:40 ` Dmitry Antipov
2012-11-09 7:24 ` Eli Zaretskii
2012-11-09 8:56 ` Eli Zaretskii
2012-11-09 12:44 ` Dmitry Antipov
2012-11-09 14:47 ` Eli Zaretskii
2012-11-09 13:17 ` Dmitry Antipov
2012-11-09 13:27 ` Dmitry Antipov
2012-11-09 14:16 ` Eli Zaretskii
2012-11-09 14:46 ` Dmitry Antipov
2012-11-09 14:53 ` Eli Zaretskii
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.