bug#72559: 31.0.50; profiler-report-write-profile produced unreadable data

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 72559@debbugs.gnu.org
> Date: Sat, 10 Aug 2024 13:56:49 +0000
> From:  Pip Cet via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> "Ihor Radchenko" <yantar92@posteo.net> writes:
> 
> > Since ~few months ago, I started having issues with profiler dumps
> > shared by users.  The latest example is in
> > https://list.orgmode.org/87r0axvu7y.fsf@gmail.com/T/#u
> >
> > When trying to open the profiler data with M-x profiler-find-profile, I
> > keep getting
> > profiler-find-profile: Invalid read syntax: "#<", 2, 64028
> > or similar errors.
> 
> (Just trying to save others the work of going to character 64028 in that
> dump).
> 
> In that example, the relevant section of the dump looks like this:
> 
> #[0 "..." [#<killed buffer> buffer-name kill-buffer] 2]
> 
> Which looks like a byte code closure produced by make-closure, probably
> by with-temp-buffer:

I think the problem is that we now dump the buttons into the saved
profile.  We also write symbols as strings.  Two examples:

  ["redisplay_internal (C function)" "nil" "nil" "nil" "nil" "nil" "nil" "nil" "nil" "nil" "nil" "nil" "nil" "nil" "nil" "nil"]

  [#("vertical-motion" 0 15 (help-args (vertical-motion) category help-function-button button (t))) #("line-move-visual" 0 16 (help-args (line-move-visual) category help-function-button button (t))) #("line-move" 0 9 (help-args (line-move) category help-function-button button (t))) #("previous-line" 0 13 (help-args (previous-line) category help-function-button button (t))) #("funcall-interactively" 0 21 (help-args (funcall-interactively) category help-function-button button (t))) #("call-interactively" 0 18 (help-args (call-interactively) category help-function-button button (t))) #("command-execute" 0 15 (help-args (command-execute) category help-function-button button (t))) "nil" "nil" "nil" "nil" "nil" "nil" "nil" "nil" "nil"]

And finally, even reading a profile written by Emacs 29 produces bogus
entries, like #<string 847> instead of  #<compiled 0xe6a63a01a3790bb>.

So something is seriously foobar in profiler.el, or maybe in the
printing infrastructure it uses.