Subject: bug#72559: closed (Re: bug#72559: 31.0.50; profiler-report-write-profile produced unreadable data)

From: [email-masked] (GNU bug Tracking System)
Date: Sat, 17 Aug 2024 17:51:02 +0000

Your bug report

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

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
72559: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=72559
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#72559: 31.0.50; profiler-report-write-profile produced unreadable data
From: Eli Zaretskii <[email-masked]>
To: Stefan Monnier <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Date: Sat, 17 Aug 2024 20:49:22 +0300
List-Id: <debbugs-submit.debbugs.gnu.org>

> From: Stefan Monnier <[email-masked]>
> Cc: [email-masked],  [email-masked],  [email-masked]
> Date: Sat, 17 Aug 2024 13:35:07 -0400
> 
> >> I don't think we want to write them as function objects, because then
> >> we'll again bump into the problem that some function objects contain
> >> unprintable objects like buffers.
> > But Emacs 29 does succeed there, at least in my testing, including
> > when the profile shows byte-compiled functions.  So how come Emacs 30
> > cannot?
> 
> Emacs-29 did:
> 
>     (defun profiler-format-entry (entry)
>       "Format ENTRY in human readable string.
>     ENTRY would be a function name of a function itself."
>       (cond ((memq (car-safe entry) '(closure lambda))
>              (format "#<lambda %#x>" (sxhash entry)))
>             ((byte-code-function-p entry)
>              (format "#<compiled %#x>" (sxhash entry)))
>             ((or (subrp entry) (symbolp entry) (stringp entry))
>              (format "%s" entry))
>             (t
>              (format "#<unknown %#x>" (sxhash entry)))))
> 
>     (defun profiler-fixup-entry (entry)
>       (if (symbolp entry)
>           entry
>         (profiler-format-entry entry)))
> 
> IOW it did not save the actual function object but only some kind of
> "name" (like we do now).
> 
> And then when using such a saved backtrace, the `stringp` above made it
> print just that name.  My suggestion above (as in the patch below) just
> re-instates that previous behavior.

Thanks, installed on the emacs-30 branch, and closing the bug.

Subject: 31.0.50; profiler-report-write-profile produced unreadable data
From: Ihor Radchenko <[email-masked]>
To: [email-masked]
Date: Sat, 10 Aug 2024 12:41:52 +0000
List-Id: <debbugs-submit.debbugs.gnu.org>

Hello,

Since ~few months ago, I started having issues with profiler dumps
shared by users.  The latest example is in
https://list.orgmode.org/[email-masked]/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.

In other words, unreadable objects are somehow dumped, rendering the
profiles useless.

To reproduce,
1. emacs -Q
2. M-x profiler-start RET cpu RET
3. M-x profiler-report
4. M-x profiler-report-write-profile /tmp/1.eld
5. M-x profiler-find-profile /tmp/1.eld

In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.42, cairo version 1.18.0) of 2024-07-26 built on localhost
Repository revision: ba708a0681eced555585fb8281f24b75b32c4178
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101013
System Description: Gentoo Linux

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>