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

[David PONCE <david.ponce@wanadoo.fr>]

> 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