Re: [Stephen.Berman@gmx.net: Emacs hangs while edebugging recentf.el]

Re: [Stephen.Berman@gmx.net: Emacs hangs while edebugging recentf.el]

[David PONCE]

> Would you please DTRT and then ack?

Sorry for the delay to reply.

[...]
> I'm not sure if this is a real bug or some limitation in the way
> edebug works.  I did the following:
> 1. emacs -q
> 2. M-x load-library RET recentf RET
> 3. M-x recentf-mode
> 4. M-: (setq recentf-list
[...]
> 5. Click on File->Open Recent->Options and set Recentf Menu Filter to
> recentf-arrange-by-mode for current session.
> 6. In the lisp source recentf.el instrument recentf-open-files for
> edebug (C-u M-C-x).
> 7. M-x recentf-open-files
> 8. Step through the function until this sexp:
>    (apply 'widget-create
>            `(group
>              :indent 2
>              :format "\n%v\n"
>              ,@(recentf-open-files-items (or files recentf-list))))
> 
> When ededug hits the end of this sexp, Emacs hangs and starts
> consuming all available CPU cycles.  If I quickly press C-g the
> hanging stops.
[...]

I reproduced the error and also found that Emacs hangs in the built-in
function `prin1-to-string' when it tries to print the value the
function `widget-create' returns, which contains a lot of circular
references in a deeply nested list.  If I don't interrupt the hang,
after some time, the function fails with a "Memory exhausted" message.
Notice that the widgets are correctly created in the "*Open Recent*"
buffer.  This is only the edebug prin1 function that hangs.

When I set the value of `edebug-print-level' to 10 instead of the
default value of 50, Emacs no more hangs.

Maybe there is a bug in the prin1-to-string function?  Unfortunately I
don't know how to fix it.

Or perhaps the default values of `edebug-print-level' and
`edebug-print-length' are too big?

Hope it helps.

David

Re: [Stephen.Berman@gmx.net: Emacs hangs while edebugging recentf.el]

[Richard M. Stallman]

    I reproduced the error and also found that Emacs hangs in the built-in
    function `prin1-to-string' when it tries to print the value the
    function `widget-create' returns, which contains a lot of circular
    references in a deeply nested list.  If I don't interrupt the hang,
    after some time, the function fails with a "Memory exhausted" message.
    Notice that the widgets are correctly created in the "*Open Recent*"
    buffer.  This is only the edebug prin1 function that hangs.

    When I set the value of `edebug-print-level' to 10 instead of the
    default value of 50, Emacs no more hangs.

    Maybe there is a bug in the prin1-to-string function?  Unfortunately I
    don't know how to fix it.

It could be a bug in prin1-to-string.  What is the value
of print-circle at that time?

Re: [Stephen.Berman@gmx.net: Emacs hangs while edebugging recentf.el]

[Richard M. Stallman]

    I reproduced the error and also found that Emacs hangs in the built-in
    function `prin1-to-string' when it tries to print the value the
    function `widget-create' returns, which contains a lot of circular
    references in a deeply nested list.  If I don't interrupt the hang,
    after some time, the function fails with a "Memory exhausted" message.
    Notice that the widgets are correctly created in the "*Open Recent*"
    buffer.  This is only the edebug prin1 function that hangs.

    When I set the value of `edebug-print-level' to 10 instead of the
    default value of 50, Emacs no more hangs.

    Maybe there is a bug in the prin1-to-string function?  Unfortunately I
    don't know how to fix it.

Can someone investigate that bug?  David Ponce said he can't.

Re: [Stephen.Berman@gmx.net: Emacs hangs while edebugging recentf.el]

[Chong Yidong]

"Richard M. Stallman" <rms@gnu.org> writes:

>     I reproduced the error and also found that Emacs hangs in the built-in
>     function `prin1-to-string' when it tries to print the value the
>     function `widget-create' returns, which contains a lot of circular
>     references in a deeply nested list.  If I don't interrupt the hang,
>     after some time, the function fails with a "Memory exhausted" message.
>     Notice that the widgets are correctly created in the "*Open Recent*"
>     buffer.  This is only the edebug prin1 function that hangs.
>
>     When I set the value of `edebug-print-level' to 10 instead of the
>     default value of 50, Emacs no more hangs.
>
>     Maybe there is a bug in the prin1-to-string function?  Unfortunately I
>     don't know how to fix it.
>
> Can someone investigate that bug?  David Ponce said he can't.

I think the trouble is that the way print_preprocess "follows" nested
lists, while handling print_depth, is slightly different from the way
print_object does it.  Because of this, it is possible for
print_preprocess to give up sooner than print_object would.  An object
could thus fail to be put into Vprint_number_table, even though
print_object later is later called for it.

There is a quick but inelegant way to cover up this bug:

*** emacs/src/print.c.~1.214.~	2005-11-10 08:45:06.000000000 -0500
--- emacs/src/print.c	2005-12-13 17:17:49.000000000 -0500
***************
*** 1313,1319 ****
  
    /* Give up if we go so deep that print_object will get an error.  */
    /* See similar code in print_object.  */
!   if (print_depth >= PRINT_CIRCLE)
      return;
  
    /* Avoid infinite recursion for circular nested structure
--- 1313,1319 ----
  
    /* Give up if we go so deep that print_object will get an error.  */
    /* See similar code in print_object.  */
!   if (print_depth > 2 * PRINT_CIRCLE)
      return;
  
    /* Avoid infinite recursion for circular nested structure

Re: [Stephen.Berman@gmx.net: Emacs hangs while edebugging recentf.el]

[Richard M. Stallman]

Please install your fix.

Re: [Stephen.Berman@gmx.net: Emacs hangs while edebugging recentf.el]

[David PONCE]

Hi,

> It could be a bug in prin1-to-string.  What is the value
> of print-circle at that time?

It is t.  It is let-bound by the function `edebug-safe-prin1-to-string'
that wraps the built-in `prin1-to-string'.  Here are the relevant parts
of edebug code:

...

(defcustom edebug-print-length 50
  "*Default value of `print-length' for printing results in Edebug."
  :type 'integer
  :group 'edebug)
(defcustom edebug-print-level 50
  "*Default value of `print-level' for printing results in Edebug."
  :type 'integer
  :group 'edebug)
(defcustom edebug-print-circle t
  "*Default value of `print-circle' for printing results in Edebug."
  :type 'boolean
  :group 'edebug)

...

;; Define here in case they are not already defined.
(defvar print-level nil)
(defvar print-circle nil)
(defvar print-readably) ;; defined by lemacs
;; Alternatively, we could change the definition of
;; edebug-safe-prin1-to-string to only use these if defined.

(defun edebug-safe-prin1-to-string (value)
  (let ((print-escape-newlines t)
	(print-length (or edebug-print-length print-length))
	(print-level (or edebug-print-level print-level))
	(print-circle (or edebug-print-circle print-circle))
	(print-readably nil)) ;; lemacs uses this.
    (edebug-prin1-to-string value)))

...

`edebug-prin1-to-string' is an alias for `prin1-to-string'.

Sincerely,
David

Re: [Stephen.Berman@gmx.net: Emacs hangs while edebugging recentf.el]

[Richard M. Stallman]

    > It could be a bug in prin1-to-string.  What is the value
    > of print-circle at that time?

    It is t.  It is let-bound by the function `edebug-safe-prin1-to-string'
    that wraps the built-in `prin1-to-string'.

I did some debugging.  It seems to be a repeating recursion in print,
which should not happen because the print-circle feature should
prevent it.  Clearly there is a bug in that feature.  A backtrace
shows some objects repeating in one stack frame after another.

I started to try to figure out why.  One repeating argument was the
13th link in the list that's the 8th element of the value being
printed.  So the question is why that is not in Vprint_number_table
There must be a bug in print_preprocess, but I can't see it.

I ran out of time to debug this.  Can someone else investigate?