bug#12839: 24.3.50; Emacs aborts in GC

bug#12839: 24.3.50; Emacs aborts in GC

[Eli Zaretskii]

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)

bug#12839: 24.3.50; Emacs aborts in GC

[Eli Zaretskii]

> 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.

bug#12839: 24.3.50; Emacs aborts in GC

[Dmitry Antipov]

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

bug#12839: 24.3.50; Emacs aborts in GC

[Eli Zaretskii]

> 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

bug#12839: 24.3.50; Emacs aborts in GC

[Eli Zaretskii]

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

bug#12839: 24.3.50; Emacs aborts in GC

[Dmitry Antipov]

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

bug#12839: 24.3.50; Emacs aborts in GC

[Dmitry Antipov]

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

bug#12839: 24.3.50; Emacs aborts in GC

[Dmitry Antipov]

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

bug#12839: 24.3.50; Emacs aborts in GC

[Eli Zaretskii]

> 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?

bug#12839: 24.3.50; Emacs aborts in GC

[Dmitry Antipov]

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

bug#12839: 24.3.50; Emacs aborts in GC

[Eli Zaretskii]

> 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?

bug#12839: 24.3.50; Emacs aborts in GC

[Eli Zaretskii]

> 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.