--- Begin Message ---
|
Subject: |
31.0.50; profiler-report-write-profile produced unreadable data |
|
Date: |
Sat, 10 Aug 2024 12:41:52 +0000 |
Hello,
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.
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>
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#72559: 31.0.50; profiler-report-write-profile produced unreadable data |
|
Date: |
Sat, 17 Aug 2024 20:49:22 +0300 |
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: pipcet@protonmail.com, yantar92@posteo.net, 72559@debbugs.gnu.org
> 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.
--- End Message ---