unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation]
@ 2005-11-28  4:46 Richard M. Stallman
  0 siblings, 0 replies; 23+ messages in thread
From: Richard M. Stallman @ 2005-11-28  4:46 UTC (permalink / raw)


Would someone please investigate this bug, and ack?

------- Start of forwarded message -------
From: "Drew Adams" <drew.adams@oracle.com>
To: "Emacs-Pretest-Bug" <emacs-pretest-bug@gnu.org>
Date: Tue, 22 Nov 2005 09:32:25 -0800
In-Reply-To: <MEEKKIABFKKDFJMPIOEBKEHKCNAA.drew.adams@oracle.com>
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
Subject: RE: weird defadvice bug with byte-compilation
Sender: emacs-pretest-bug-bounces+rms=gnu.org@gnu.org
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on monty-python
X-Spam-Level: 
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63

Not sure if anyone is looking into this bug. I know it sounds as if it's
quite particular (corner case), but I suspect that this may point to
something improper in the byte-compiler code. And it does systematically
produce a fatal error. - Drew

- ----------

    This is a weird one. I've pared it down to the bare bones, I think -
    if I comment out any part of this, the bug doesn't occur. This
    obviously comes from a larger context - when it is pared down, the
    code doesn't make much sense, of course.

    If the stuff is in the same file, or the order is different, no bug
    (error). It must be like this: two files, one of which is compiled and
    required by the other. And the requiring file must have "compile" in
    its defadvice.

    Two files:

    File 1: foo.el
    --------------

    (defvar mymap nil "")

    (let ((map (make-sparse-keymap "II")))
      (setq mymap (make-sparse-keymap))
      (define-key menu-bar-search-menu [ise]  '("" . ise))
      (put 'ise 'menu-enable '(and my-mode))
      (push (cons 'my-mode mymap) minor-mode-map-alist))

    (defadvice next-history-element (after ffff activate) "" my-mode)

    (provide 'foo)

    File 2: bar.el
    --------------

    (defconst special-display-regexps '("[ ]?[*][^*]+[*]"))

    (defvar drews-lisp-dir "C:\\drews-lisp-20" "")
    (setq load-path (append (list drews-lisp-dir) load-path))


    (defadvice occur-mode-goto-occurrence
      (around jjjjjj activate compile)
      ""
      ad-do-it)

    (require 'foo)

    Instructions:
    -------------

    1. emacs -q

    2. Byte-compile foo.el (it doesn't matter if it's compiled on Emacs 20
       or 22). `C-x C-c'.

    3. emacs -q    (Emacs 22)

    4. Visit bar.el - don't load it.

    5. Select everything in bar.el except the (require 'foo), and
    do `eval-region'.

    6. Put the cursor just after the (require 'foo) and do `C-x
    C-e'. (Don't select it and do eval-region - that doesn't
    produce the bug!)

    You will get this error backtrace:

    Debugger entered--Lisp error: (void-variable my-mode)
      (and my-mode)
      x-create-frame(((visibility) (height . 14) (width . 80)
    (unsplittable . t)))
      x-create-frame-with-faces(((height . 14) (width . 80)
    (unsplittable . t)))
      make-frame(((height . 14) (width . 80) (unsplittable . t)))
      special-display-popup-frame(#<buffer *Compile-Log*>)
      display-buffer(#<buffer *Compile-Log*>)
      display-warning(bytecomp "reference to free variable
    `my-mode'" :warning "*Compile-Log*")
      byte-compile-log-warning("reference to free variable
    `my-mode'" t :warning)
      byte-compile-warn("reference to free variable `%s'" my-mode)
      byte-compile-variable-ref(byte-varref my-mode)
      byte-compile-form(my-mode t)
      byte-compile-body(((setq ad-return-value
    (ad-Orig-next-history-element n)) my-mode ad-return-value) nil)
      byte-compile-let((let (ad-return-value) (setq ad-return-value
    (ad-Orig-next-history-element n)) my-mode ad-return-value))
      byte-compile-form((let (ad-return-value) (setq
    ad-return-value (ad-Orig-next-history-element n)) my-mode
    ad-return-value) nil)
      byte-compile-top-level((progn (let (ad-return-value) (setq
    ad-return-value ...) my-mode ad-return-value)) nil lambda)
      byte-compile-lambda((lambda (n) "$ad-doc:
    next-history-element$" (interactive "p") (let (ad-return-value)
    (setq ad-return-value ...) my-mode ad-return-value)))
      #[nil "???			\n
    \f
    \x0e\x0e??


    7. `C-x C-c'

    You will get a pop-up message with Yes/No buttons that says this:

    Emacs Abort Dialog

    "A fatal error has occurred! Would you like to attach a
    debugger? Select YES to debu, NO to abort Emacs"

    If you select Yes, you get a Window program exception and an
    invitation to send the details to Microsoft. The error report
    contents are these:

    Exception Information
    Code 0x80000003 Flags: 0x00000000
    Record: 0x0000000000000000 (didn't count 'em) Address:
    0x0000000077f75a58

    System Information
    Windows NT 5.1 Build: 2600
    CPU Vendor Code etc. blah blah blah

    Module 1
    emacs.exe
    blah blah

    Module 2
    ntdll.dll
    blah blah

    Module 3
    kernel32.dll
    blah blah

    Module 4
    msvcrt.dll
    blah blah

    etc. etc.

    ------------------------------------
    In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600)
     of 2005-06-26 on NONIQPC
    X server distributor `Microsoft Corp.', version 5.1.2600
    configured using `configure --with-gcc (3.3) --cflags
    -I../../jpeg-6b-3/include -I../../libpng-1.2.8/include
    -I../../tiff-3.6.1-2/include -I../../xpm-nox-4.2.0/include
    -I../../zlib-1.2.2/include'





_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation]
@ 2005-12-05  2:36 Richard Stallman
  2005-12-07 18:55 ` Chong Yidong
  0 siblings, 1 reply; 23+ messages in thread
From: Richard Stallman @ 2005-12-05  2:36 UTC (permalink / raw)


Would someone please investigate this bug, and ack?
It needs to be debugged for the release.

------- Start of forwarded message -------
From: "Drew Adams" <drew.adams@oracle.com>
To: "Emacs-Pretest-Bug" <emacs-pretest-bug@gnu.org>
Date: Tue, 22 Nov 2005 09:32:25 -0800
In-Reply-To: <MEEKKIABFKKDFJMPIOEBKEHKCNAA.drew.adams@oracle.com>
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
Subject: RE: weird defadvice bug with byte-compilation
Sender: emacs-pretest-bug-bounces+rms=gnu.org@gnu.org
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on monty-python
X-Spam-Level: 
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63

Not sure if anyone is looking into this bug. I know it sounds as if it's
quite particular (corner case), but I suspect that this may point to
something improper in the byte-compiler code. And it does systematically
produce a fatal error. - Drew

- ----------

    This is a weird one. I've pared it down to the bare bones, I think -
    if I comment out any part of this, the bug doesn't occur. This
    obviously comes from a larger context - when it is pared down, the
    code doesn't make much sense, of course.

    If the stuff is in the same file, or the order is different, no bug
    (error). It must be like this: two files, one of which is compiled and
    required by the other. And the requiring file must have "compile" in
    its defadvice.

    Two files:

    File 1: foo.el
    --------------

    (defvar mymap nil "")

    (let ((map (make-sparse-keymap "II")))
      (setq mymap (make-sparse-keymap))
      (define-key menu-bar-search-menu [ise]  '("" . ise))
      (put 'ise 'menu-enable '(and my-mode))
      (push (cons 'my-mode mymap) minor-mode-map-alist))

    (defadvice next-history-element (after ffff activate) "" my-mode)

    (provide 'foo)

    File 2: bar.el
    --------------

    (defconst special-display-regexps '("[ ]?[*][^*]+[*]"))

    (defvar drews-lisp-dir "C:\\drews-lisp-20" "")
    (setq load-path (append (list drews-lisp-dir) load-path))


    (defadvice occur-mode-goto-occurrence
      (around jjjjjj activate compile)
      ""
      ad-do-it)

    (require 'foo)

    Instructions:
    -------------

    1. emacs -q

    2. Byte-compile foo.el (it doesn't matter if it's compiled on Emacs 20
       or 22). `C-x C-c'.

    3. emacs -q    (Emacs 22)

    4. Visit bar.el - don't load it.

    5. Select everything in bar.el except the (require 'foo), and
    do `eval-region'.

    6. Put the cursor just after the (require 'foo) and do `C-x
    C-e'. (Don't select it and do eval-region - that doesn't
    produce the bug!)

    You will get this error backtrace:

    Debugger entered--Lisp error: (void-variable my-mode)
      (and my-mode)
      x-create-frame(((visibility) (height . 14) (width . 80)
    (unsplittable . t)))
      x-create-frame-with-faces(((height . 14) (width . 80)
    (unsplittable . t)))
      make-frame(((height . 14) (width . 80) (unsplittable . t)))
      special-display-popup-frame(#<buffer *Compile-Log*>)
      display-buffer(#<buffer *Compile-Log*>)
      display-warning(bytecomp "reference to free variable
    `my-mode'" :warning "*Compile-Log*")
      byte-compile-log-warning("reference to free variable
    `my-mode'" t :warning)
      byte-compile-warn("reference to free variable `%s'" my-mode)
      byte-compile-variable-ref(byte-varref my-mode)
      byte-compile-form(my-mode t)
      byte-compile-body(((setq ad-return-value
    (ad-Orig-next-history-element n)) my-mode ad-return-value) nil)
      byte-compile-let((let (ad-return-value) (setq ad-return-value
    (ad-Orig-next-history-element n)) my-mode ad-return-value))
      byte-compile-form((let (ad-return-value) (setq
    ad-return-value (ad-Orig-next-history-element n)) my-mode
    ad-return-value) nil)
      byte-compile-top-level((progn (let (ad-return-value) (setq
    ad-return-value ...) my-mode ad-return-value)) nil lambda)
      byte-compile-lambda((lambda (n) "$ad-doc:
    next-history-element$" (interactive "p") (let (ad-return-value)
    (setq ad-return-value ...) my-mode ad-return-value)))
      #[nil "???			\n
    \f
    \x0e\x0e??


    7. `C-x C-c'

    You will get a pop-up message with Yes/No buttons that says this:

    Emacs Abort Dialog

    "A fatal error has occurred! Would you like to attach a
    debugger? Select YES to debu, NO to abort Emacs"

    If you select Yes, you get a Window program exception and an
    invitation to send the details to Microsoft. The error report
    contents are these:

    Exception Information
    Code 0x80000003 Flags: 0x00000000
    Record: 0x0000000000000000 (didn't count 'em) Address:
    0x0000000077f75a58

    System Information
    Windows NT 5.1 Build: 2600
    CPU Vendor Code etc. blah blah blah

    Module 1
    emacs.exe
    blah blah

    Module 2
    ntdll.dll
    blah blah

    Module 3
    kernel32.dll
    blah blah

    Module 4
    msvcrt.dll
    blah blah

    etc. etc.

    ------------------------------------
    In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600)
     of 2005-06-26 on NONIQPC
    X server distributor `Microsoft Corp.', version 5.1.2600
    configured using `configure --with-gcc (3.3) --cflags
    -I../../jpeg-6b-3/include -I../../libpng-1.2.8/include
    -I../../tiff-3.6.1-2/include -I../../xpm-nox-4.2.0/include
    -I../../zlib-1.2.2/include'





_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation]
  2005-12-05  2:36 Richard Stallman
@ 2005-12-07 18:55 ` Chong Yidong
  2005-12-08  4:53   ` Richard M. Stallman
  0 siblings, 1 reply; 23+ messages in thread
From: Chong Yidong @ 2005-12-07 18:55 UTC (permalink / raw)
  Cc: emacs-devel

Richard Stallman <rms@gnu.org> writes:

> Would someone please investigate this bug, and ack?
> It needs to be debugged for the release.

I can't seem to reproduce this on GNU/Linux.  It may be a Windows-only
bug (unless it's been fixed already).

> From: "Drew Adams" <drew.adams@oracle.com>
>
>     File 1: foo.el
>     --------------
>
>     (defvar mymap nil "")
>
>     (let ((map (make-sparse-keymap "II")))
>       (setq mymap (make-sparse-keymap))
>       (define-key menu-bar-search-menu [ise]  '("" . ise))
>       (put 'ise 'menu-enable '(and my-mode))
>       (push (cons 'my-mode mymap) minor-mode-map-alist))
>
>     (defadvice next-history-element (after ffff activate) "" my-mode)
>
>     (provide 'foo)
>
>     File 2: bar.el
>     --------------
>
>     (defconst special-display-regexps '("[ ]?[*][^*]+[*]"))
>
>     (defvar drews-lisp-dir "C:\\drews-lisp-20" "")
>     (setq load-path (append (list drews-lisp-dir) load-path))
>
>
>     (defadvice occur-mode-goto-occurrence
>       (around jjjjjj activate compile)
>       ""
>       ad-do-it)
>
>     (require 'foo)
>
>     Instructions:
>     -------------
>
>     1. emacs -q
>
>     2. Byte-compile foo.el (it doesn't matter if it's compiled on Emacs 20
>        or 22). `C-x C-c'.
>
>     3. emacs -q    (Emacs 22)
>
>     4. Visit bar.el - don't load it.
>
>     5. Select everything in bar.el except the (require 'foo), and
>     do `eval-region'.
>
>     6. Put the cursor just after the (require 'foo) and do `C-x
>     C-e'. (Don't select it and do eval-region - that doesn't
>     produce the bug!)
>
>     7. `C-x C-c'
>
>     You will get a pop-up message with Yes/No buttons that says this:
>
>     Emacs Abort Dialog
>
>     "A fatal error has occurred! Would you like to attach a
>     debugger? Select YES to debu, NO to abort Emacs"

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation]
  2005-12-07 18:55 ` Chong Yidong
@ 2005-12-08  4:53   ` Richard M. Stallman
  2005-12-08 16:14     ` Drew Adams
  0 siblings, 1 reply; 23+ messages in thread
From: Richard M. Stallman @ 2005-12-08  4:53 UTC (permalink / raw)
  Cc: drew.adams, emacs-devel

    > Would someone please investigate this bug, and ack?
    > It needs to be debugged for the release.

    I can't seem to reproduce this on GNU/Linux.  It may be a Windows-only
    bug (unless it's been fixed already).

Thanks for investigating.  It could be fixed already.
So we can forget about it unless we get a new report
based on the latest sources.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* RE: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation]
  2005-12-08  4:53   ` Richard M. Stallman
@ 2005-12-08 16:14     ` Drew Adams
  2005-12-09 13:17       ` Eli Zaretskii
  0 siblings, 1 reply; 23+ messages in thread
From: Drew Adams @ 2005-12-08 16:14 UTC (permalink / raw)


        > Would someone please investigate this bug, and ack?
        > It needs to be debugged for the release.

        I can't seem to reproduce this on GNU/Linux.  It may be a
        Windows-only bug (unless it's been fixed already).

    Thanks for investigating.  It could be fixed already.
    So we can forget about it unless we get a new report
    based on the latest sources.

Yes, thanks for looking into it. Hopefully it was already fixed, and is not
a Windows-specific problem.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation]
  2005-12-08 16:14     ` Drew Adams
@ 2005-12-09 13:17       ` Eli Zaretskii
  2005-12-09 14:07         ` Chong Yidong
                           ` (2 more replies)
  0 siblings, 3 replies; 23+ messages in thread
From: Eli Zaretskii @ 2005-12-09 13:17 UTC (permalink / raw)
  Cc: Chong Yidong, emacs-devel

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Thu, 8 Dec 2005 08:14:55 -0800
> 
>         > Would someone please investigate this bug, and ack?
>         > It needs to be debugged for the release.
> 
>         I can't seem to reproduce this on GNU/Linux.  It may be a
>         Windows-only bug (unless it's been fixed already).
> 
>     Thanks for investigating.  It could be fixed already.
>     So we can forget about it unless we get a new report
>     based on the latest sources.
> 
> Yes, thanks for looking into it. Hopefully it was already fixed, and is not
> a Windows-specific problem.

I'm not sure it was fixed.  Chong Yidong didn't say what he saw on
GNU/Linux when he tried this, but on MS-Windows, with today's CVS, I
see the following (after replacing "C:\\drews-lisp-20" with the
directory where I put foo.el and bar.el --- Chong, did you do that on
GNU/Linux?):

  . Typing "C-x C-e" to evaluate `(require 'foo)' throws an error:

    Debugger entered--Lisp error: (void-variable my-mode)
      (and my-mode)
      x-create-frame(((visibility) (height . 14) (width . 80) (unsplittable . t)))
      x-create-frame-with-faces(((height . 14) (width . 80) (unsplittable . t)))
      make-frame(((height . 14) (width . 80) (unsplittable . t)))
      special-display-popup-frame(#<buffer *Compile-Log*>)
      display-buffer(#<buffer *Compile-Log*>)
      display-warning(bytecomp "reference to free variable `my-mode'" :warning "*Compile-Log*")
      byte-compile-log-warning("reference to free variable `my-mode'" t :warning)
      byte-compile-warn("reference to free variable `%s'" my-mode)
      byte-compile-variable-ref(byte-varref my-mode)
      byte-compile-form(my-mode t)
      byte-compile-body(((setq ad-return-value (ad-Orig-next-history-element n)) my-mode ad-return-value) nil)
      byte-compile-let((let (ad-return-value) (setq ad-return-value (ad-Orig-next-history-element n)) my-mode ad-return-value))
      byte-compile-form((let (ad-return-value) (setq ad-return-value (ad-Orig-next-history-element n)) my-mode ad-return-value) nil)
      byte-compile-top-level((progn (let (ad-return-value) (setq ad-return-value ...) my-mode ad-return-value)) nil lambda)
      byte-compile-lambda((lambda (n) "$ad-doc: next-history-element$" (interactive "p") (let (ad-return-value) (setq ad-return-value ...) my-mode ad-return-value)))
      #[nil "...."
      byte-compile(advice-compilation)
      ad-compile-function(next-history-element)
      ad-activate-advised-definition(next-history-element nil)
      ad-activate(next-history-element nil)
      byte-code("...")
      require(foo)
      eval((require (quote foo)))
      eval-last-sexp-1(nil)
      eval-last-sexp(nil)
      call-interactively(eval-last-sexp)

      (I omitted the byte-codes and replaced them with ellipsis "...".)

   .  Typing "C-x C-c" at this point, i.e., after the above traceback
      was shown, does pop up the Emacs Abort Dialog.

The Lisp error is thrown for a good reason, AFAICT: `my-mode' was
never defined.  Drew, should it be?

If I run Emacs from GDB, I get the following backtrace after I click
YES in the abort dialog:

    (gdb) bt 20
    #0  0x7c901231 in ntdll!DbgUiConnectToDbg () from ntdll.dll
    #1  0x011319c7 in w32_abort () at w32fns.c:8949
    #2  0x01084cee in check_glyph_memory () at dispnew.c:2583
    #3  0x010018c3 in shut_down_emacs (sig=0, no_x=0, stuff=23861249)
	at emacs.c:2167
    #4  0x01001929 in Fkill_emacs (arg=23861249) at emacs.c:2072
    #5  0x0100c5da in Ffuncall (nargs=1, args=0x82c1b0) at eval.c:2879
    #6  0x011094f9 in Fbyte_code (bytestr=18486379, vector=18486500, maxdepth=40)
	at bytecode.c:694
    #7  0x0100bfae in funcall_lambda (fun=18486332, nargs=1, arg_vector=0x82c374)
	at eval.c:3066
    #8  0x0100c3a1 in Ffuncall (nargs=2, args=0x82c370) at eval.c:2934
    #9  0x01107858 in Fcall_interactively (function=24463457,
	record_flag=23861249, keys=23920644) at callint.c:884
    #10 0x0104ca3e in Fcommand_execute (cmd=24463457, record_flag=23861249,
	keys=23861249, special=23861249) at keyboard.c:9734
    #11 0x01053279 in command_loop_1 () at keyboard.c:1777
    #12 0x0100a81b in internal_condition_case (bfun=0x1052f39 <command_loop_1>,
	handlers=23925361, hfun=0x104d397 <cmd_error>) at eval.c:1465
    #13 0x010479b7 in command_loop_2 () at keyboard.c:1315
    #14 0x0100a750 in internal_catch (tag=23949793,
	func=0x1047994 <command_loop_2>, arg=23861249) at eval.c:1211
    #15 0x0104777f in command_loop () at keyboard.c:1282
    #16 0x01047867 in recursive_edit_1 () at keyboard.c:987
    #17 0x0104797d in Frecursive_edit () at keyboard.c:1048
    #18 0x0100c5e5 in Ffuncall (nargs=1, args=0x82c880) at eval.c:2876
    #19 0x011094f9 in Fbyte_code (bytestr=32152067, vector=27025668, maxdepth=32)
	at bytecode.c:694
    (More stack frames follow...)

    Lisp Backtrace:
    "kill-emacs"
    "save-buffers-kill-emacs"
    "call-interactively"
    "recursive-edit"
    "byte-code"
    "debug"
    "and"
    "x-create-frame"
    "x-create-frame-with-faces"
    "make-frame"
    "special-display-popup-frame"
    "display-buffer"
    "display-warning"
    "byte-compile-log-warning"
    "byte-compile-warn"

I will try to debug this when I have time (any ideas are welcome), but
in the meantime, I see already that the problem that causes Emacs to
commit suicide in frame #2 is that glyph_matrix_count is 8 instead of
0.  Here's the code of check_glyph_memory:

    /* Check glyph memory leaks.  This function is called from
       shut_down_emacs.  Note that frames are not destroyed when Emacs
       exits.  We therefore free all glyph memory for all active frames
       explicitly and check that nothing is left allocated.  */

    void
    check_glyph_memory ()
    {
      Lisp_Object tail, frame;

      /* Free glyph memory for all frames.  */
      FOR_EACH_FRAME (tail, frame)
	free_glyphs (XFRAME (frame));

      /* Check that nothing is left allocated.  */
      if (glyph_matrix_count)
	abort ();
      if (glyph_pool_count)
	abort ();
    }

It sounds like some frame's glyph matrices were not freed for some
reason?

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation]
  2005-12-09 13:17       ` Eli Zaretskii
@ 2005-12-09 14:07         ` Chong Yidong
  2005-12-10  4:14         ` Richard M. Stallman
  2005-12-11 20:21         ` Eli Zaretskii
  2 siblings, 0 replies; 23+ messages in thread
From: Chong Yidong @ 2005-12-09 14:07 UTC (permalink / raw)
  Cc: Drew Adams, emacs-devel

> I'm not sure it was fixed.  Chong Yidong didn't say what he saw on
> GNU/Linux when he tried this, but on MS-Windows, with today's CVS, I
> see the following (after replacing "C:\\drews-lisp-20" with the
> directory where I put foo.el and bar.el --- Chong, did you do that on
> GNU/Linux?):
>
>    .  Typing "C-x C-c" at this point, i.e., after the above traceback
>       was shown, does pop up the Emacs Abort Dialog.

On GNU/Linux, `C-x C-c' at this point just exits Emacs.  I didn't see
any abort dialog.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation]
  2005-12-09 13:17       ` Eli Zaretskii
  2005-12-09 14:07         ` Chong Yidong
@ 2005-12-10  4:14         ` Richard M. Stallman
  2005-12-11 20:21         ` Eli Zaretskii
  2 siblings, 0 replies; 23+ messages in thread
From: Richard M. Stallman @ 2005-12-10  4:14 UTC (permalink / raw)
  Cc: cyd, drew.adams, emacs-devel

    Debugger entered--Lisp error: (void-variable my-mode)
      (and my-mode)
      x-create-frame(((visibility) (height . 14) (width . 80) (unsplittable . t)))
      x-create-frame-with-faces(((height . 14) (width . 80) (unsplittable . t)))
      make-frame(((height . 14) (width . 80) (unsplittable . t)))

I think I see the reason for this error:

    (let ((map (make-sparse-keymap "II")))
      (setq mymap (make-sparse-keymap))
      (define-key menu-bar-search-menu [ise]  '("" . ise))
      (put 'ise 'menu-enable '(and my-mode))

The menu command's enable condition tests a void variable.
So this error seems to be correct.

    It sounds like some frame's glyph matrices were not freed for some
    reason?

Or maybe they were originally used, and counted, more times
than they should have been.

So I think the first question is, was glyph_matrix_count correct
before check_glyph_memory was called?  If so, there must be a bug in
free_glyphs.  If it was not correct, then how did it get to be wrong?

I suspect that it has to do with getting an error while
part way through creating a frame.  Maybe that left an inconsistent
value for glyph_matrix_count.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation]
  2005-12-09 13:17       ` Eli Zaretskii
  2005-12-09 14:07         ` Chong Yidong
  2005-12-10  4:14         ` Richard M. Stallman
@ 2005-12-11 20:21         ` Eli Zaretskii
  2005-12-12  5:23           ` Richard M. Stallman
  2 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2005-12-11 20:21 UTC (permalink / raw)
  Cc: emacs-devel

> Date: Fri, 09 Dec 2005 15:17:06 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: Chong Yidong <cyd@stupidchicken.com>, emacs-devel@gnu.org
> 
>     Lisp Backtrace:
>     "kill-emacs"
>     "save-buffers-kill-emacs"
>     "call-interactively"
>     "recursive-edit"
>     "byte-code"
>     "debug"
>     "and"
>     "x-create-frame"
>     "x-create-frame-with-faces"
>     "make-frame"
>     "special-display-popup-frame"
>     "display-buffer"
>     "display-warning"
>     "byte-compile-log-warning"
>     "byte-compile-warn"
> 
> I will try to debug this when I have time (any ideas are welcome), but
> in the meantime, I see already that the problem that causes Emacs to
> commit suicide in frame #2 is that glyph_matrix_count is 8 instead of
> 0.  Here's the code of check_glyph_memory:
> 
>     /* Check glyph memory leaks.  This function is called from
>        shut_down_emacs.  Note that frames are not destroyed when Emacs
>        exits.  We therefore free all glyph memory for all active frames
>        explicitly and check that nothing is left allocated.  */
> 
>     void
>     check_glyph_memory ()
>     {
>       Lisp_Object tail, frame;
> 
>       /* Free glyph memory for all frames.  */
>       FOR_EACH_FRAME (tail, frame)
> 	free_glyphs (XFRAME (frame));
> 
>       /* Check that nothing is left allocated.  */
>       if (glyph_matrix_count)
> 	abort ();
>       if (glyph_pool_count)
> 	abort ();
>     }
> 
> It sounds like some frame's glyph matrices were not freed for some
> reason?

I did some debugging.  I do not yet have all the answers, but the fog
is beginning to clear.

First, I think that a Unix or GNU/Linux build on X, but without any
toolkits (no GTK, no Motif/Lesstiff, no Xt), might hit this bug as
well.  Can someone please try that?  I cannot easily build and test
such a version on GNU boxes to which I have access.

Second, the crash is somehow related to the fact that x-create-frame
is called from within itself, or something like that: When advice
byte-compiles the advised function on the fly, it hits the problem
with the unbound variable, and wants to display a warning in the
*Compile-Log* buffer.  However, due to this line from bar.el:

    (defconst special-display-regexps '("[ ]?[*][^*]+[*]"))

*Compile-Log* is one of the buffers that need a separate frame, so
Emacs begins to create a frame.  During that frame's creation, it
hits the problem with the void variable again, and wants to display
the backtrace, but the *Backtrace* buffer also needs a separate
frame...

Here's the relevant portion of the Lisp backtrace:

    Debugger entered--Lisp error: (void-variable my-mode)
      (and my-mode)
      x-create-frame(((visibility) (height . 14) (width . 80) (unsplittable . t)))
      x-create-frame-with-faces(((height . 14) (width . 80) (unsplittable . t)))
      make-frame(((height . 14) (width . 80) (unsplittable . t)))
      special-display-popup-frame(#<buffer *Compile-Log*>)
      display-buffer(#<buffer *Compile-Log*>)
      display-warning(bytecomp "reference to free variable `my-mode'" :warning "*Compile-Log*")
      byte-compile-log-warning("reference to free variable `my-mode'" t :warning)
      byte-compile-warn("reference to free variable `%s'" my-mode)
      byte-compile-variable-ref(byte-varref my-mode)
      byte-compile-form(my-mode t)
      byte-compile-body(((setq ad-return-value (ad-Orig-next-history-element n)) my-mode ad-return-value) nil)

When the frame displaying *Backtrace* pops up, the variable
Vframe_list does not yet include the frame that was partly created to
display *Compile-Log*, so check_glyph_memory does not free that
frame's glyph matrices.

Does this make sense?

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation]
  2005-12-11 20:21         ` Eli Zaretskii
@ 2005-12-12  5:23           ` Richard M. Stallman
  2005-12-12  6:11             ` Eli Zaretskii
  0 siblings, 1 reply; 23+ messages in thread
From: Richard M. Stallman @ 2005-12-12  5:23 UTC (permalink / raw)
  Cc: cyd, drew.adams, emacs-devel

    Second, the crash is somehow related to the fact that x-create-frame
    is called from within itself, or something like that:

Very interesting.  Can you send me the C backtrace?  That's what
matters here.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation]
  2005-12-12  5:23           ` Richard M. Stallman
@ 2005-12-12  6:11             ` Eli Zaretskii
  2005-12-13  3:14               ` Richard M. Stallman
  0 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2005-12-12  6:11 UTC (permalink / raw)
  Cc: cyd, drew.adams, emacs-devel

> From: "Richard M. Stallman" <rms@gnu.org>
> CC: drew.adams@oracle.com, cyd@stupidchicken.com, emacs-devel@gnu.org
> Date: Mon, 12 Dec 2005 00:23:33 -0500
> 
>     Second, the crash is somehow related to the fact that x-create-frame
>     is called from within itself, or something like that:
> 
> Very interesting.  Can you send me the C backtrace?  That's what
> matters here.

I posted the C backtrace in this thread.  Here is a more full version:

    Program received signal SIGTRAP, Trace/breakpoint trap.
    [Switching to thread 2924.0x948]
    0x7c901231 in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
    (gdb) bt 40
    #0  0x7c901231 in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
    #1  0x011319c7 in w32_abort () at w32fns.c:8953
    #2  0x01084cee in check_glyph_memory () at dispnew.c:2583
    #3  0x010018c3 in shut_down_emacs (sig=0, no_x=0, stuff=23861249)
	at emacs.c:2170
    #4  0x01001929 in Fkill_emacs (arg=23861249) at emacs.c:2075
    #5  0x0100c5da in Ffuncall (nargs=1, args=0x82c1b0) at eval.c:2879
    #6  0x011094f9 in Fbyte_code (bytestr=18486379, vector=18486500, maxdepth=40)
	at bytecode.c:694
    #7  0x0100bfae in funcall_lambda (fun=18486332, nargs=1, arg_vector=0x82c374)
	at eval.c:3066
    #8  0x0100c3a1 in Ffuncall (nargs=2, args=0x82c370) at eval.c:2934
    #9  0x01107858 in Fcall_interactively (function=24463457,
	record_flag=23861249, keys=23920644) at callint.c:884
    #10 0x0104ca3e in Fcommand_execute (cmd=24463457, record_flag=23861249,
	keys=23861249, special=23861249) at keyboard.c:9751
    #11 0x01053279 in command_loop_1 () at keyboard.c:1780
    #12 0x0100a81b in internal_condition_case (bfun=0x1052f39 <command_loop_1>,
	handlers=23925361, hfun=0x104d397 <cmd_error>) at eval.c:1465
    #13 0x010479b7 in command_loop_2 () at keyboard.c:1318
    #14 0x0100a750 in internal_catch (tag=23949793,
	func=0x1047994 <command_loop_2>, arg=23861249) at eval.c:1211
    #15 0x0104777f in command_loop () at keyboard.c:1285
    #16 0x01047867 in recursive_edit_1 () at keyboard.c:990
    #17 0x0104797d in Frecursive_edit () at keyboard.c:1051
    #18 0x0100c5e5 in Ffuncall (nargs=1, args=0x82c880) at eval.c:2876
    #19 0x011094f9 in Fbyte_code (bytestr=26968867, vector=27021828, maxdepth=32)
	at bytecode.c:694
    #20 0x0100baf6 in Feval (form=26208213) at eval.c:2225
    #21 0x0100bdc3 in Fprogn (args=26207965) at eval.c:432
    #22 0x0109cbaa in Fsave_window_excursion (args=26207965) at window.c:6368
    #23 0x01109ef2 in Fbyte_code (bytestr=26969027, vector=29856260, maxdepth=224)
	at bytecode.c:855
    #24 0x0100bfae in funcall_lambda (fun=29723972, nargs=2, arg_vector=0x82cbd4)
	at eval.c:3066
    #25 0x0100c3a1 in Ffuncall (nargs=3, args=0x82cbd0) at eval.c:2934
    #26 0x0100d8c3 in Fapply (nargs=2, args=0x82cc48) at eval.c:2371
    #27 0x0100d9c1 in apply1 (fn=24109177, arg=26176261) at eval.c:2632
    #28 0x0100b270 in call_debugger (arg=26176261) at eval.c:289
    #29 0x0100b576 in find_handler_clause (handlers=23925361, conditions=23847045,
	sig=23925529, data=26176285, debugger_value_ptr=0x82cce8) at eval.c:1815
    #30 0x0100c93a in Fsignal (error_symbol=23925529, data=26176285) at eval.c:1642
    #31 0x01005ad2 in Fsymbol_value (symbol=29457225) at data.c:1143
    #32 0x0100b84c in Feval (form=29457225) at eval.c:2105
    #33 0x0100e1d4 in Fand (args=25815637) at eval.c:353
    #34 0x0100bbdb in Feval (form=25815653) at eval.c:2166
    #35 0x0100a588 in internal_condition_case_1 (bfun=0x100b5de <Feval>,
	arg=25815653, handlers=23925361,
	hfun=0x104b17c <menu_item_eval_property_1>) at eval.c:1506
    #36 0x0104b206 in menu_item_eval_property (sexpr=25815653) at keyboard.c:7193
    #37 0x0104b6a1 in parse_menu_item (item=25816925, notreal=0, inmenubar=0)
	at keyboard.c:7380
    #38 0x0112ad43 in single_menu_item (key=29457273, item=525205504,
	pending_maps_ptr=0x82d09c, notreal=0, maxdepth=9) at w32menu.c:522
    #39 0x0112b02e in single_keymap_panes (keymap=29457273, pane_name=2089878893,
	prefix=9, notreal=17085537, maxdepth=24812917) at w32menu.c:468
    (More stack frames follow...)

    Lisp Backtrace:
    "kill-emacs"
    "save-buffers-kill-emacs"
    "call-interactively"
    "recursive-edit"
    "byte-code"
    "debug"
    "and"
    "x-create-frame"
    "x-create-frame-with-faces"
    "make-frame"
    "special-display-popup-frame"
    "display-buffer"
    "display-warning"
    "byte-compile-log-warning"
    "byte-compile-warn"
    "byte-compile-variable-ref"
    "byte-compile-form"
    "byte-compile-body"
    "byte-compile-let"
    "byte-compile-form"
    "byte-compile-top-level"
    "byte-compile-lambda"
    0x1d22e84 PVEC_COMPILED
    "funcall"
    "byte-compile"
    "ad-compile-function"
    "ad-activate-advised-definition"
    "ad-activate"
    "byte-code"
    "require"
    "eval"
    "eval-last-sexp-1"
    "eval-last-sexp"
    "call-interactively"
    (gdb)

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation]
  2005-12-12  6:11             ` Eli Zaretskii
@ 2005-12-13  3:14               ` Richard M. Stallman
  2005-12-13  4:39                 ` Eli Zaretskii
  0 siblings, 1 reply; 23+ messages in thread
From: Richard M. Stallman @ 2005-12-13  3:14 UTC (permalink / raw)
  Cc: cyd, drew.adams, emacs-devel

	#36 0x0104b206 in menu_item_eval_property (sexpr=25815653) at keyboard.c:7193
	#37 0x0104b6a1 in parse_menu_item (item=25816925, notreal=0, inmenubar=0)
	    at keyboard.c:7380
	#38 0x0112ad43 in single_menu_item (key=29457273, item=525205504,
	    pending_maps_ptr=0x82d09c, notreal=0, maxdepth=9) at w32menu.c:522
	#39 0x0112b02e in single_keymap_panes (keymap=29457273, pane_name=2089878893,
	    prefix=9, notreal=17085537, maxdepth=24812917) at w32menu.c:468
	(More stack frames follow...)

You cut it off just as it's starting to get interesting!

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation]
  2005-12-13  3:14               ` Richard M. Stallman
@ 2005-12-13  4:39                 ` Eli Zaretskii
  2005-12-13 23:33                   ` Richard M. Stallman
  0 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2005-12-13  4:39 UTC (permalink / raw)
  Cc: emacs-devel

> From: "Richard M. Stallman" <rms@gnu.org>
> CC: drew.adams@oracle.com, cyd@stupidchicken.com, emacs-devel@gnu.org
> Date: Mon, 12 Dec 2005 22:14:53 -0500
> 
> 	#36 0x0104b206 in menu_item_eval_property (sexpr=25815653) at keyboard.c:7193
> 	#37 0x0104b6a1 in parse_menu_item (item=25816925, notreal=0, inmenubar=0)
> 	    at keyboard.c:7380
> 	#38 0x0112ad43 in single_menu_item (key=29457273, item=525205504,
> 	    pending_maps_ptr=0x82d09c, notreal=0, maxdepth=9) at w32menu.c:522
> 	#39 0x0112b02e in single_keymap_panes (keymap=29457273, pane_name=2089878893,
> 	    prefix=9, notreal=17085537, maxdepth=24812917) at w32menu.c:468
> 	(More stack frames follow...)
> 
> You cut it off just as it's starting to get interesting!

Tell me what you want to know or see, and I will make sure it's not
cut off.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation]
  2005-12-13  4:39                 ` Eli Zaretskii
@ 2005-12-13 23:33                   ` Richard M. Stallman
  2005-12-14 19:38                     ` Eli Zaretskii
  0 siblings, 1 reply; 23+ messages in thread
From: Richard M. Stallman @ 2005-12-13 23:33 UTC (permalink / raw)
  Cc: emacs-devel

    > 	#38 0x0112ad43 in single_menu_item (key=29457273, item=525205504,
    > 	    pending_maps_ptr=0x82d09c, notreal=0, maxdepth=9) at w32menu.c:522
    > 	#39 0x0112b02e in single_keymap_panes (keymap=29457273, pane_name=2089878893,
    > 	    prefix=9, notreal=17085537, maxdepth=24812917) at w32menu.c:468
    > 	(More stack frames follow...)
    > 
    > You cut it off just as it's starting to get interesting!

    Tell me what you want to know or see, and I will make sure it's not
    cut off.

Where does it come from in Fx_create_frame?

If there are two frames that call Fx_create_frame, I need
to see both.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation]
  2005-12-13 23:33                   ` Richard M. Stallman
@ 2005-12-14 19:38                     ` Eli Zaretskii
  2005-12-15  2:09                       ` Richard M. Stallman
  0 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2005-12-14 19:38 UTC (permalink / raw)
  Cc: emacs-devel

> From: "Richard M. Stallman" <rms@gnu.org>
> CC: emacs-devel@gnu.org
> Date: Tue, 13 Dec 2005 18:33:42 -0500
> 
>     > 	#38 0x0112ad43 in single_menu_item (key=29457273, item=525205504,
>     > 	    pending_maps_ptr=0x82d09c, notreal=0, maxdepth=9) at w32menu.c:522
>     > 	#39 0x0112b02e in single_keymap_panes (keymap=29457273, pane_name=2089878893,
>     > 	    prefix=9, notreal=17085537, maxdepth=24812917) at w32menu.c:468
>     > 	(More stack frames follow...)
>     > 
>     > You cut it off just as it's starting to get interesting!
> 
>     Tell me what you want to know or see, and I will make sure it's not
>     cut off.
> 
> Where does it come from in Fx_create_frame?
> 
> If there are two frames that call Fx_create_frame, I need
> to see both.

Unfortunately, I cannot show this in the C traceback, because GDB
chokes on the next stack frame:

    #39 0x0112ae03 in single_menu_item (key=28443961, item=0,
	pending_maps_ptr=0x82d09c, notreal=0, maxdepth=9) at w32menu.c:522
    #40 0x0112b0ee in single_keymap_panes (keymap=28443961, pane_name=0, prefix=9,
	notreal=17085537, maxdepth=24660221) at w32menu.c:468
    #41 0x00000000 in ?? () from
    #42 0x00000009 in ?? ()
    #43 0x0104b461 in parse_menu_item (item=480, notreal=8573128,
	inmenubar=18001130) at keyboard.c:7376
    #44 0x01c76008 in ?? ()
    #45 0x000001e0 in ?? ()
    #46 0x0082d0c8 in ?? ()
    #47 0x0112acea in grow_menu_items () at w32menu.c:329
    #48 0x01011575 in x_y_to_hpos_vpos (w=0x1b20539, x=Cannot access memory at address 0x1b016c00) at xdisp.c:1005
    Cannot access memory at address 0x1b016c14

But the Lisp traceback clearly shows the recursive call:

    "x-create-frame"
    "x-create-frame-with-faces"
    "make-frame"
    "special-display-popup-frame"
    "pop-to-buffer"
    "byte-code"
    "debug"
    "and"
    "x-create-frame"
    "x-create-frame-with-faces"
    "make-frame"
    "special-display-popup-frame"
    "display-buffer"
    "display-warning"
    "byte-compile-log-warning"
    "byte-compile-warn"
    "byte-compile-variable-ref"
    "byte-compile-form"
    "byte-compile-body"
    "byte-compile-let"
    "byte-compile-form"
    "byte-compile-top-level"
    "byte-compile-lambda"
    0x1c2cf24 PVEC_COMPILED
    "funcall"
    "byte-compile"
    "ad-compile-function"
    "ad-activate-advised-definition"
    "ad-activate"
    "byte-code"
    "require"
    "eval"
    "eval-last-sexp-1"
    "eval-last-sexp"
    "call-interactively"

I think the recursion happens when Emacs builds the menu bar for the
new frame.  The C functions that build menu items, which show in the C
traceback, are an evidence to that effect.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation]
  2005-12-14 19:38                     ` Eli Zaretskii
@ 2005-12-15  2:09                       ` Richard M. Stallman
  2005-12-15  4:46                         ` Eli Zaretskii
  0 siblings, 1 reply; 23+ messages in thread
From: Richard M. Stallman @ 2005-12-15  2:09 UTC (permalink / raw)
  Cc: emacs-devel

    Unfortunately, I cannot show this in the C traceback, because GDB
    chokes on the next stack frame:

	#39 0x0112ae03 in single_menu_item (key=28443961, item=0,
	    pending_maps_ptr=0x82d09c, notreal=0, maxdepth=9) at w32menu.c:522
	#40 0x0112b0ee in single_keymap_panes (keymap=28443961, pane_name=0, prefix=9,
	    notreal=17085537, maxdepth=24660221) at w32menu.c:468
	#41 0x00000000 in ?? () from
	#42 0x00000009 in ?? ()
	#43 0x0104b461 in parse_menu_item (item=480, notreal=8573128,
	    inmenubar=18001130) at keyboard.c:7376
	#44 0x01c76008 in ?? ()
	#45 0x000001e0 in ?? ()
	#46 0x0082d0c8 in ?? ()
	#47 0x0112acea in grow_menu_items () at w32menu.c:329
	#48 0x01011575 in x_y_to_hpos_vpos (w=0x1b20539, x=Cannot access memory at address 0x1b016c00) at xdisp.c:1005
	Cannot access memory at address 0x1b016c14

This means the stack is corrupted.  We need to find out why and how,
because that could be the most important bug.

This is probably straightforward and not too hard.  It has to happen
inside that call to x_y_to_hpos_vpos.  By inserting some breakpoints
at places where control passes within that frame, and at each one
examining the backtrace, you can see it gets clobbered between point X
and point Y.  Then try again with breakpoints or stepping between X
and Y, and localize it more narrowly.  Eventually you find exactly
where it happens, and the problem is usually obvious when you look
at the code in that line.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation]
  2005-12-15  2:09                       ` Richard M. Stallman
@ 2005-12-15  4:46                         ` Eli Zaretskii
  2005-12-16  1:51                           ` Richard M. Stallman
  0 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2005-12-15  4:46 UTC (permalink / raw)
  Cc: emacs-devel

> From: "Richard M. Stallman" <rms@gnu.org>
> CC: emacs-devel@gnu.org
> Date: Wed, 14 Dec 2005 21:09:16 -0500
> 
>     Unfortunately, I cannot show this in the C traceback, because GDB
>     chokes on the next stack frame:
> 
> 	#39 0x0112ae03 in single_menu_item (key=28443961, item=0,
> 	    pending_maps_ptr=0x82d09c, notreal=0, maxdepth=9) at w32menu.c:522
> 	#40 0x0112b0ee in single_keymap_panes (keymap=28443961, pane_name=0, prefix=9,
> 	    notreal=17085537, maxdepth=24660221) at w32menu.c:468
> 	#41 0x00000000 in ?? () from
> 	#42 0x00000009 in ?? ()
> 	#43 0x0104b461 in parse_menu_item (item=480, notreal=8573128,
> 	    inmenubar=18001130) at keyboard.c:7376
> 	#44 0x01c76008 in ?? ()
> 	#45 0x000001e0 in ?? ()
> 	#46 0x0082d0c8 in ?? ()
> 	#47 0x0112acea in grow_menu_items () at w32menu.c:329
> 	#48 0x01011575 in x_y_to_hpos_vpos (w=0x1b20539, x=Cannot access memory at address 0x1b016c00) at xdisp.c:1005
> 	Cannot access memory at address 0x1b016c14
> 
> This means the stack is corrupted.  We need to find out why and how,
> because that could be the most important bug.

No, the stack is not corrupted.  The problem is that latest versions
of GDB modified their way of analyzing function prologues, and that
caused major regressions in stack backtraces on x86, especially with
latest versions of GCC.  That has been discussed extensively on the
GDB mailing list during the last year.

GDB 6.4 is supposed to improve on that, but I don't yet have its
Windows port.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation]
  2005-12-15  4:46                         ` Eli Zaretskii
@ 2005-12-16  1:51                           ` Richard M. Stallman
  2005-12-16 19:48                             ` Eli Zaretskii
  2005-12-16 20:14                             ` Eli Zaretskii
  0 siblings, 2 replies; 23+ messages in thread
From: Richard M. Stallman @ 2005-12-16  1:51 UTC (permalink / raw)
  Cc: emacs-devel

    > This means the stack is corrupted.  We need to find out why and how,
    > because that could be the most important bug.

    No, the stack is not corrupted.  The problem is that latest versions
    of GDB modified their way of analyzing function prologues, and that
    caused major regressions in stack backtraces on x86, especially with
    latest versions of GCC.  That has been discussed extensively on the
    GDB mailing list during the last year.

    GDB 6.4 is supposed to improve on that, but I don't yet have its
    Windows port.

In that case, with a breakpoint at x_y_to_hpos_vpos
do you see more stack trace info?

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation]
  2005-12-16  1:51                           ` Richard M. Stallman
@ 2005-12-16 19:48                             ` Eli Zaretskii
  2005-12-16 20:14                             ` Eli Zaretskii
  1 sibling, 0 replies; 23+ messages in thread
From: Eli Zaretskii @ 2005-12-16 19:48 UTC (permalink / raw)
  Cc: emacs-devel

> From: "Richard M. Stallman" <rms@gnu.org>
> CC: emacs-devel@gnu.org
> Date: Thu, 15 Dec 2005 20:51:15 -0500
> 
> In that case, with a breakpoint at x_y_to_hpos_vpos
> do you see more stack trace info?

It was not that easy (needed to find the correct sequence of `step',
`finish', and `next' commands to get the info), but the results are
below.  As you see, menu_item_eval_property, which is called as part
of building the menu items, causes Feval to be called, which then
enters the debugger, which in turn causes another frame to be created
in the middle of creating the frame for *Compile-Log*.

  #0  new_glyph_matrix (pool=0x0) at dispnew.c:523
  #1  0x01084400 in allocate_matrices_for_window_redisplay (w=0x1d77e00)
      at dispnew.c:2052
  #2  0x010846b5 in adjust_frame_glyphs (f=0x1d77000) at dispnew.c:2380
  #3  0x01084a94 in adjust_glyphs (f=0x1d77000) at dispnew.c:2081
  #4  0x010d910b in x_set_frame_parameters (f=0x1d77000, alist=30471261)
      at frame.c:2780
  #5  0x010dab97 in x_default_parameter (f=0x1d77000, alist=30471949,
      prop=24041361, deflt=8, xprop=0x12b4870 "menuBar",
      xclass=0x12b4868 "MenuBar", type=RES_TYPE_NUMBER) at frame.c:3635
  #6  0x01137e16 in Fx_create_frame (parameters=30471949) at w32fns.c:4275
  #7  0x0100c5da in Ffuncall (nargs=2, args=0x82c3b8) at eval.c:2879
  #8  0x011095d9 in Fbyte_code (bytestr=18525555, vector=18525636, maxdepth=40)
      at bytecode.c:694
  #9  0x0100bfae in funcall_lambda (fun=18525508, nargs=1, arg_vector=0x82c504)
      at eval.c:3066
  #10 0x0100c3a1 in Ffuncall (nargs=2, args=0x82c500) at eval.c:2934
  #11 0x011095d9 in Fbyte_code (bytestr=18940947, vector=18940988, maxdepth=24)
      at bytecode.c:694
  #12 0x0100bfae in funcall_lambda (fun=18940900, nargs=1, arg_vector=0x82c644)
      at eval.c:3066
  #13 0x0100c3a1 in Ffuncall (nargs=2, args=0x82c640) at eval.c:2934
  #14 0x011095d9 in Fbyte_code (bytestr=18935771, vector=18935916, maxdepth=40)
      at bytecode.c:694
  #15 0x0100bfae in funcall_lambda (fun=18935716, nargs=1, arg_vector=0x82c79c)
      at eval.c:3066
  #16 0x0100c3a1 in Ffuncall (nargs=2, args=0x82c798) at eval.c:2934
  #17 0x0100d4ef in call1 (fn=26425137, arg1=30856708) at eval.c:2664
  #18 0x0106288f in Fpop_to_buffer (buffer=30856708, other_window=23861249,
      norecord=23861249) at buffer.c:1726
  #19 0x0100c5b3 in Ffuncall (nargs=2, args=0x82c880) at eval.c:2885
  #20 0x011095d9 in Fbyte_code (bytestr=30877059, vector=26801924, maxdepth=32)
      at bytecode.c:694
  #21 0x0100baf6 in Feval (form=30363701) at eval.c:2225
  #22 0x0100bdc3 in Fprogn (args=30363477) at eval.c:432
  #23 0x0109cc0a in Fsave_window_excursion (args=30363477) at window.c:6368
  #24 0x01109fd2 in Fbyte_code (bytestr=30876899, vector=30855684, maxdepth=224)
      at bytecode.c:855
  #25 0x0100bfae in funcall_lambda (fun=30392004, nargs=2, arg_vector=0x82cbd4)
      at eval.c:3066
  #26 0x0100c3a1 in Ffuncall (nargs=3, args=0x82cbd0) at eval.c:2934
  #27 0x0100d8c3 in Fapply (nargs=2, args=0x82cc48) at eval.c:2371
  #28 0x0100d9c1 in apply1 (fn=24109177, arg=30366645) at eval.c:2632
  #29 0x0100b270 in call_debugger (arg=30366645) at eval.c:289
  #30 0x0100b576 in find_handler_clause (handlers=23925361, conditions=23847045,
      sig=23925529, data=30366677, debugger_value_ptr=0x82cce8) at eval.c:1815
  #31 0x0100c93a in Fsignal (error_symbol=23925529, data=30366677) at eval.c:1642
  #32 0x01005ad2 in Fsymbol_value (symbol=29501537) at data.c:1143
  #33 0x0100b84c in Feval (form=29501537) at eval.c:2105
  #34 0x0100e1d4 in Fand (args=25851101) at eval.c:353
  #35 0x0100bbdb in Feval (form=25851109) at eval.c:2166
  #36 0x0100a588 in internal_condition_case_1 (bfun=0x100b5de <Feval>,
      arg=25851109, handlers=23925361,
      hfun=0x104b18c <menu_item_eval_property_1>) at eval.c:1506
  #37 0x0104b216 in menu_item_eval_property (sexpr=25851109) at keyboard.c:7193
  #38 0x0104b6b1 in parse_menu_item (item=25851149, notreal=0, inmenubar=0)
      at keyboard.c:7380
  #39 0x0112ae23 in single_menu_item (key=29501585, item=0,
      pending_maps_ptr=0x82d09c, notreal=0, maxdepth=9) at w32menu.c:522
  #40 0x0112b10e in single_keymap_panes (keymap=29501585, pane_name=0, prefix=9,
      notreal=17085553, maxdepth=24812205) at w32menu.c:468
  #41 parse_single_submenu (item_key, item_name, maps) at w32menu.c:1499
  #42 set_frame_menubar (f=0x16ca400, first_time=1, deep_p=1) at w32menu.c:1406
  #43 0x0112c4f8 in initialize_frame_menubar () at w32menu.c:1666
  #44 0x0113863a in Fx_create_frame (parameters=25605765) at w32fns.c:3951
  #45 0x0100c5da in Ffuncall (nargs=2, args=0x82d728) at eval.c:2879
  #46 0x011095d9 in Fbyte_code (bytestr=18525555, vector=18525636, maxdepth=40)
      at bytecode.c:694
  #47 0x0100bfae in funcall_lambda (fun=18525508, nargs=1, arg_vector=0x82d874)
      at eval.c:3066
  #48 0x0100c3a1 in Ffuncall (nargs=2, args=0x82d870) at eval.c:2934
  #49 0x011095d9 in Fbyte_code (bytestr=18940883, vector=18940924, maxdepth=24)
      at bytecode.c:694
  #50 0x0100bfae in funcall_lambda (fun=18940836, nargs=1, arg_vector=0x82d9b4)
      at eval.c:3066
  #51 0x0100c3a1 in Ffuncall (nargs=2, args=0x82d9b0) at eval.c:2934
  #52 0x011095d9 in Fbyte_code (bytestr=18935707, vector=18935852, maxdepth=40)
      at bytecode.c:694
  #53 0x0100bfae in funcall_lambda (fun=18935652, nargs=1, arg_vector=0x82db0c)
      at eval.c:3066
  #54 0x0100c3a1 in Ffuncall (nargs=2, args=0x82db08) at eval.c:2934
  #55 0x0100d4ef in call1 (fn=26426113, arg1=23898116) at eval.c:2664
  #56 0x0100c5b3 in Ffuncall (nargs=2, args=0x82dbd0) at eval.c:2885
  #57 0x011095d9 in Fbyte_code (bytestr=29441059, vector=30482180, maxdepth=48)
      at bytecode.c:694
  #58 0x0100bfae in funcall_lambda (fun=26442500, nargs=4, arg_vector=0x82dd24)
      at eval.c:3066
  #59 0x0100c3a1 in Ffuncall (nargs=5, args=0x82dd20) at eval.c:2934
  #60 0x011095d9 in Fbyte_code (bytestr=29697891, vector=30697668, maxdepth=40)
      at bytecode.c:694
  #61 0x0100bfae in funcall_lambda (fun=30763684, nargs=3, arg_vector=0x82de74)
      at eval.c:3066
  #62 0x0100c3a1 in Ffuncall (nargs=4, args=0x82de70) at eval.c:2934
  #63 0x011095d9 in Fbyte_code (bytestr=29697715, vector=30697604, maxdepth=32)
      at bytecode.c:694
  #64 0x0100bfae in funcall_lambda (fun=30763524, nargs=2, arg_vector=0x82dfb4)
      at eval.c:3066
  #65 0x0100c3a1 in Ffuncall (nargs=3, args=0x82dfb0) at eval.c:2934
  #66 0x011095d9 in Fbyte_code (bytestr=29622083, vector=30771204, maxdepth=64)
      at bytecode.c:694
  #67 0x0100bfae in funcall_lambda (fun=30781956, nargs=2, arg_vector=0x82e104)
      at eval.c:3066
  #68 0x0100c3a1 in Ffuncall (nargs=3, args=0x82e100) at eval.c:2934
  #69 0x011095d9 in Fbyte_code (bytestr=29621939, vector=30771460, maxdepth=32)
      at bytecode.c:694
  #70 0x0100bfae in funcall_lambda (fun=30782308, nargs=2, arg_vector=0x82e244)
      at eval.c:3066
  #71 0x0100c3a1 in Ffuncall (nargs=3, args=0x82e240) at eval.c:2934
  #72 0x011095d9 in Fbyte_code (bytestr=30831027, vector=30817284, maxdepth=32)
      at bytecode.c:694
  #73 0x0100bfae in funcall_lambda (fun=30817156, nargs=2, arg_vector=0x82e384)
      at eval.c:3066
  #74 0x0100c3a1 in Ffuncall (nargs=3, args=0x82e380) at eval.c:2934
  #75 0x011095d9 in Fbyte_code (bytestr=30867779, vector=30821892, maxdepth=32)
      at bytecode.c:694
  #76 0x0100bfae in funcall_lambda (fun=30826180, nargs=1, arg_vector=0x82e4c4)
      at eval.c:3066
  #77 0x0100c3a1 in Ffuncall (nargs=2, args=0x82e4c0) at eval.c:2934
  #78 0x011095d9 in Fbyte_code (bytestr=29621939, vector=30771460, maxdepth=32)
      at bytecode.c:694
  #79 0x0100bfae in funcall_lambda (fun=30782308, nargs=2, arg_vector=0x82e604)
      at eval.c:3066
  #80 0x0100c3a1 in Ffuncall (nargs=3, args=0x82e600) at eval.c:2934
  #81 0x011095d9 in Fbyte_code (bytestr=29621795, vector=30704260, maxdepth=56)
      at bytecode.c:694
  #82 0x0100bfae in funcall_lambda (fun=30782820, nargs=3, arg_vector=0x82e754)
      at eval.c:3066
  #83 0x0100c3a1 in Ffuncall (nargs=4, args=0x82e750) at eval.c:2934
  #84 0x011095d9 in Fbyte_code (bytestr=29621651, vector=30771972, maxdepth=64)
      at bytecode.c:694
  #85 0x0100bfae in funcall_lambda (fun=30783140, nargs=1, arg_vector=0x82e8a4)
      at eval.c:3066
  #86 0x0100c3a1 in Ffuncall (nargs=2, args=0x82e8a0) at eval.c:2934
  #87 0x011095d9 in Fbyte_code (bytestr=29621395, vector=30705028, maxdepth=112)
      at bytecode.c:694
  #88 0x0100bfae in funcall_lambda (fun=30784260, nargs=0, arg_vector=0x82ea24)
      at eval.c:3066
  #89 0x0100c3a1 in Ffuncall (nargs=1, args=0x82ea20) at eval.c:2934
  #90 0x0100bb14 in Feval (form=29790573) at eval.c:2222
  #91 0x0100dca3 in internal_lisp_condition_case (var=29436577,
      bodyform=29790573, handlers=26199045) at eval.c:1412
  #92 0x01109f4b in Fbyte_code (bytestr=29621379, vector=30704900, maxdepth=24)
      at bytecode.c:884
  #93 0x0100bfae in funcall_lambda (fun=30784100, nargs=1, arg_vector=0x82ecf4)
      at eval.c:3066
  #94 0x0100c3a1 in Ffuncall (nargs=2, args=0x82ecf0) at eval.c:2934
  #95 0x011095d9 in Fbyte_code (bytestr=30868643, vector=28317700, maxdepth=24)
      at bytecode.c:694
  #96 0x0100bfae in funcall_lambda (fun=26665668, nargs=1, arg_vector=0x82ee34)
      at eval.c:3066
  #97 0x0100c3a1 in Ffuncall (nargs=2, args=0x82ee30) at eval.c:2934
  #98 0x011095d9 in Fbyte_code (bytestr=29493683, vector=30699204, maxdepth=56)
      at bytecode.c:694
  #99 0x0100bfae in funcall_lambda (fun=30701988, nargs=2, arg_vector=0x82ef84)
      at eval.c:3066
  #100 0x0100c3a1 in Ffuncall (nargs=3, args=0x82ef80) at eval.c:2934
  #101 0x011095d9 in Fbyte_code (bytestr=29493507, vector=30707332, maxdepth=32)
      at bytecode.c:694
  #102 0x0100bfae in funcall_lambda (fun=30701668, nargs=2, arg_vector=0x82f0c4)
      at eval.c:3066
  #103 0x0100c3a1 in Ffuncall (nargs=3, args=0x82f0c0) at eval.c:2934
  #104 0x011095d9 in Fbyte_code (bytestr=24006403, vector=24559876, maxdepth=40)
      at bytecode.c:694
  #105 0x0100baf6 in Feval (form=25931277) at eval.c:2225
  #106 0x0106a837 in readevalloop (readcharfun=23946201, stream=0x77c5fce0,
      sourcename=24464883, evalfun=0x100b5de <Feval>, printflag=0,
      unibyte=23861249, readfun=23861249, start=23861249, end=23861249)
      at lread.c:1406
  #107 0x0106b404 in Fload (file=26699395, noerror=23861249, nomessage=23861297,
      nosuffix=23861249, must_suffix=23861297) at lread.c:920
  #108 0x01078293 in Frequire (feature=29485993, filename=23861249,
      noerror=23861249) at fns.c:3618
  #109 0x0100baf6 in Feval (form=25932213) at eval.c:2225
  #110 0x0100c5da in Ffuncall (nargs=2, args=0x82f780) at eval.c:2879
  #111 0x011095d9 in Fbyte_code (bytestr=19176851, vector=19177028, maxdepth=64)
      at bytecode.c:694
  #112 0x0100bfae in funcall_lambda (fun=19176812, nargs=1, arg_vector=0x82f8d4)
      at eval.c:3066
  #113 0x0100c3a1 in Ffuncall (nargs=2, args=0x82f8d0) at eval.c:2934
  #114 0x011095d9 in Fbyte_code (bytestr=19177683, vector=19177740, maxdepth=32)
      at bytecode.c:694
  #115 0x0100bfae in funcall_lambda (fun=19177644, nargs=1, arg_vector=0x82fa84)
      at eval.c:3066
  #116 0x0100c3a1 in Ffuncall (nargs=2, args=0x82fa80) at eval.c:2934
  #117 0x01107938 in Fcall_interactively (function=24380921,
      record_flag=23861249, keys=23920644) at callint.c:884
  #118 0x0104ca4e in Fcommand_execute (cmd=24380921, record_flag=23861249,
      keys=23861249, special=23861249) at keyboard.c:9751
  #119 0x01053289 in command_loop_1 () at keyboard.c:1780
  #120 0x0100a81b in internal_condition_case (bfun=0x1052f49 <command_loop_1>,
      handlers=23925361, hfun=0x104d3a7 <cmd_error>) at eval.c:1465
  #121 0x010479c7 in command_loop_2 () at keyboard.c:1318
  #122 0x0100a750 in internal_catch (tag=23919641,
      func=0x10479a4 <command_loop_2>, arg=23861249) at eval.c:1211
  #123 0x010477e3 in command_loop () at keyboard.c:1297
  #124 0x01047877 in recursive_edit_1 () at keyboard.c:990
  #125 0x0104798d in Frecursive_edit () at keyboard.c:1051
  #126 0x010029dd in main (argc=2, argv=0xa23fa8) at emacs.c:1786

  Lisp Backtrace:
  "x-create-frame"
  "x-create-frame-with-faces"
  "make-frame"
  "special-display-popup-frame"
  "pop-to-buffer"
  "byte-code"
  "debug"
  "and"
  "x-create-frame"
  "x-create-frame-with-faces"
  "make-frame"
  "special-display-popup-frame"
  "display-buffer"
  "display-warning"
  "byte-compile-log-warning"
  "byte-compile-warn"
  "byte-compile-variable-ref"
  "byte-compile-form"
  "byte-compile-body"
  "byte-compile-let"
  "byte-compile-form"
  "byte-compile-top-level"
  "byte-compile-lambda"
  0x1993b04 PVEC_COMPILED
  "funcall"
  "byte-compile"
  "ad-compile-function"
  "ad-activate-advised-definition"
  "ad-activate"
  "byte-code"
  "require"
  "eval"
  "eval-last-sexp-1"
  "eval-last-sexp"
  "call-interactively"

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation]
  2005-12-16  1:51                           ` Richard M. Stallman
  2005-12-16 19:48                             ` Eli Zaretskii
@ 2005-12-16 20:14                             ` Eli Zaretskii
  2005-12-17  1:05                               ` Richard M. Stallman
  1 sibling, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2005-12-16 20:14 UTC (permalink / raw)
  Cc: jasonr, emacs-devel

FWIW, I found that I can prevent this crash with the simple change
below.  It registers the frame in Vframe_alist before the menu bar is
constructed, so if the latter signals an error, the frame whose menu
could not be built is nonetheless recorded in Vframe_alist, and thus
check_glyph_memory will free its glyph matrices.

The question is: is the crash an artifact of how check_glyph_memory
checks for glyph memory leaks, or does the crash indicate some deeper
problem?  In other words, is it kosher for Fx_create_frame to be
entered recursively?

Note that the version of Fx_create_frame in xfns.c creates the menu
_after_ the frame is registered, and not as part of the window
creation in x_window.  Jason, can you tell whether it is okay to move
the code that creates the menu on w32 from w32_window to
Fx_create_frame, and do that after the call to x_icon and x_make_gc?

Index: src/w32fns.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/w32fns.c,v
retrieving revision 1.261
diff -c -r1.261 w32fns.c
*** src/w32fns.c	14 Dec 2005 20:58:33 -0000	1.261
--- src/w32fns.c	16 Dec 2005 20:03:49 -0000
***************
*** 4299,4312 ****
    tem = w32_get_arg (parameters, Qunsplittable, 0, 0, RES_TYPE_BOOLEAN);
    f->no_split = minibuffer_only || EQ (tem, Qt);
  
    w32_window (f, window_prompting, minibuffer_only);
    x_icon (f, parameters);
- 
    x_make_gc (f);
  
    /* Now consider the frame official.  */
    FRAME_W32_DISPLAY_INFO (f)->reference_count++;
-   Vframe_list = Fcons (frame, Vframe_list);
  
    /* We need to do this after creating the window, so that the
       icon-creation functions can say whose icon they're describing.  */
--- 4299,4315 ----
    tem = w32_get_arg (parameters, Qunsplittable, 0, 0, RES_TYPE_BOOLEAN);
    f->no_split = minibuffer_only || EQ (tem, Qt);
  
+   /* Do this before the call to w32_window, since that can call Feval
+      (e.g., to compute the frame's menu bar) and throw an error, which
+      will leave this frame unregistered.  */
+   Vframe_list = Fcons (frame, Vframe_list);
+ 
    w32_window (f, window_prompting, minibuffer_only);
    x_icon (f, parameters);
    x_make_gc (f);
  
    /* Now consider the frame official.  */
    FRAME_W32_DISPLAY_INFO (f)->reference_count++;
  
    /* We need to do this after creating the window, so that the
       icon-creation functions can say whose icon they're describing.  */

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation]
  2005-12-16 20:14                             ` Eli Zaretskii
@ 2005-12-17  1:05                               ` Richard M. Stallman
  2005-12-17  8:29                                 ` Eli Zaretskii
  0 siblings, 1 reply; 23+ messages in thread
From: Richard M. Stallman @ 2005-12-17  1:05 UTC (permalink / raw)
  Cc: jasonr, emacs-devel

    +   /* Do this before the call to w32_window, since that can call Feval
    +      (e.g., to compute the frame's menu bar) and throw an error, which
    +      will leave this frame unregistered.  */
    +   Vframe_list = Fcons (frame, Vframe_list);
    + 
	w32_window (f, window_prompting, minibuffer_only);
	x_icon (f, parameters);
	x_make_gc (f);


Changing Vframe_list so early, before calling w32_window, could be
dangerous.  What if some part of window creation fails, or x_icon, or
x_make_gc?  While I am not sure of how things worn on Windows, if
those fail I suspect it will leave a bad situation.  You would not want
such a frame to be considered live.

I think the right fix is keep the setting of Vframe_list where it was,
and instead move the creation of the menu bar out of w32_window and
put it at a later place in Fx_create_frame.  That would make the code
more like what it is in xfns.c, where the menu bar creation step
is done later, after the frame is already safely in existence.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation]
  2005-12-17  1:05                               ` Richard M. Stallman
@ 2005-12-17  8:29                                 ` Eli Zaretskii
  2005-12-17 23:59                                   ` Richard M. Stallman
  0 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2005-12-17  8:29 UTC (permalink / raw)
  Cc: jasonr, emacs-devel

> From: "Richard M. Stallman" <rms@gnu.org>
> CC: emacs-devel@gnu.org, jasonr@gnu.org
> Date: Fri, 16 Dec 2005 20:05:24 -0500
> 
>     +   /* Do this before the call to w32_window, since that can call Feval
>     +      (e.g., to compute the frame's menu bar) and throw an error, which
>     +      will leave this frame unregistered.  */
>     +   Vframe_list = Fcons (frame, Vframe_list);
>     + 
> 	w32_window (f, window_prompting, minibuffer_only);
> 	x_icon (f, parameters);
> 	x_make_gc (f);
> 
> 
> Changing Vframe_list so early, before calling w32_window, could be
> dangerous.  What if some part of window creation fails, or x_icon, or
> x_make_gc?  While I am not sure of how things worn on Windows, if
> those fail I suspect it will leave a bad situation.  You would not want
> such a frame to be considered live.

AFAICS, only x_icon can throw an error.  We could arrange for removing
the failed frame from the list (and free its glyph matrices while at
that) if an error is thrown.

> I think the right fix is keep the setting of Vframe_list where it was,
> and instead move the creation of the menu bar out of w32_window and
> put it at a later place in Fx_create_frame.

I agree.  I asked Jason whether such a change could do any harm on
Windows.

So I understand from your response that it is okay for Fx_create_frame
to be entered recursively, yes?

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation]
  2005-12-17  8:29                                 ` Eli Zaretskii
@ 2005-12-17 23:59                                   ` Richard M. Stallman
  0 siblings, 0 replies; 23+ messages in thread
From: Richard M. Stallman @ 2005-12-17 23:59 UTC (permalink / raw)
  Cc: jasonr, emacs-devel

    So I understand from your response that it is okay for Fx_create_frame
    to be entered recursively, yes?

There is a part of it which should not be entered recursively, while
the frame is partially set up.  Before or after that part is ok.

^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, other threads:[~2005-12-17 23:59 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-11-28  4:46 [drew.adams@oracle.com: RE: weird defadvice bug with byte-compilation] Richard M. Stallman
  -- strict thread matches above, loose matches on Subject: below --
2005-12-05  2:36 Richard Stallman
2005-12-07 18:55 ` Chong Yidong
2005-12-08  4:53   ` Richard M. Stallman
2005-12-08 16:14     ` Drew Adams
2005-12-09 13:17       ` Eli Zaretskii
2005-12-09 14:07         ` Chong Yidong
2005-12-10  4:14         ` Richard M. Stallman
2005-12-11 20:21         ` Eli Zaretskii
2005-12-12  5:23           ` Richard M. Stallman
2005-12-12  6:11             ` Eli Zaretskii
2005-12-13  3:14               ` Richard M. Stallman
2005-12-13  4:39                 ` Eli Zaretskii
2005-12-13 23:33                   ` Richard M. Stallman
2005-12-14 19:38                     ` Eli Zaretskii
2005-12-15  2:09                       ` Richard M. Stallman
2005-12-15  4:46                         ` Eli Zaretskii
2005-12-16  1:51                           ` Richard M. Stallman
2005-12-16 19:48                             ` Eli Zaretskii
2005-12-16 20:14                             ` Eli Zaretskii
2005-12-17  1:05                               ` Richard M. Stallman
2005-12-17  8:29                                 ` Eli Zaretskii
2005-12-17 23:59                                   ` Richard M. Stallman

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