(wrong-type-argument (or eieio-object class) nil obj) in Emacs 28

[condy0919]

Emacs 28: commit 9c72666feac28c6adf459f1eed3a45dc60fd896a
OS: Arch Linux

The backtrace:

Debugger entered--Lisp error: (wrong-type-argument (or eieio-object class) nil obj)
  signal(wrong-type-argument ((or eieio-object class) nil obj))
  slot-value(nil expression-string)
  esup-fontify-results((#<esup-result esup-result-1568f67aa834> #<esup-result esup-result-1568f67aa856> #<esup-result esup-result-1568f67aa870> #<esup-result esup-result-1568f67aa892> #<esup-result esup-result-1568f67aa8bc> #<esup-result esup-result-1568f67aa8de> #<esup-result esup-result-1568f67aa8f8> #<esup-result esup-result-1568f67aa91a> #<esup-result esup-result-1568f67aa944> #<esup-result esup-result-1568f67aa966> #<esup-result esup-result-1568f67aa980> #<esup-result esup-result-1568f67aa9a2> #<esup-result esup-result-1568f680f778> #<esup-result esup-result-1568f680f79a> #<esup-result esup-result-1568f680f7c4> #<esup-result esup-result-1568f680f7e6> #<esup-result esup-result-1568f680f800> #<esup-result esup-result-1568f680f822> #<esup-result esup-result-1568f680f84c> #<esup-result esup-result-1568f680f86e> #<esup-result esup-result-1568f680f888> #<esup-result esup-result-1568f680f8aa> #<esup-result esup-result-1568f680f8d4> #<esup-result esup-result-1568f680f8f6> #<esup-result esup-result-1568f680f910> #<esup-result esup-result-1568f680f932> #<esup-result esup-result-1568f680f95c> #<esup-result esup-result-1568f680f97e> #<esup-result esup-result-1568f680f998> #<esup-result esup-result-1568f680f9ba> #<esup-result esup-result-1568f680f9e4> #<esup-result esup-result-1568f680fa06> #<esup-result esup-result-1568f6814a14> #<esup-result esup-result-1568f6814a36> #<esup-result esup-result-1568f6814a50> #<esup-result esup-result-1568f6814a72> #<esup-result esup-result-1568f6814a9c> #<esup-result esup-result-1568f6814abe> #<esup-result esup-result-1568f6814ad8> #<esup-result esup-result-1568f6814afa> #<esup-result esup-result-1568f6814b24> #<esup-result esup-result-1568f6814b46> #<esup-result esup-result-1568f6814b60> #<esup-result esup-result-1568f6814b82> #<esup-result esup-result-1568f6814bac> #<esup-result esup-result-1568f6814bce> #<esup-result esup-result-1568f6814be8> #<esup-result esup-result-1568f6814c0a> #<esup-result esup-result-1568f6814c34> #<esup-result esup-result-1568f6814c56> ...))
  esup-display-results()
  esup-child-process-sentinel(#<process *esup-child*> "finished\n")

Part of *esup-results* buffer

(list (esup-result (when (\\210\\312\\313\\314\\315\\316DD\\317\\320\\321\\306\\322&\\210\\312\\323\\314\\315\\324DD\\325\\320\\326\\306\\327&\\210\\312\\330\\314\\315\\331DD\\332\\320\\333\\306\\327&\\210\\312\\334\\314\\315\\335DD\\336\\306\\307\\320\\337&\\210\\312\\340\\314\\315\\341DD\\342\\320\\343\\306\\307&\\210\\312\\344\\314\\315\\345DD\\346\\320\\347\\306\\327&\\210\\312\\350\\314\\315\\351DD\\352\\320\\353\\306\\327&\\210\\312\\354\\314\\315\\355DD\\356\\320\\337\\306\\357&\\210\\312\\360\\314\\315\\361DD\\362\\320\\363\\306\\357&\\210\\312\\364\\314\\315\\365DD\\366\\320\\367\\306\\370&\\207\" [require cl-lib custom-declare-group vc-git nil \"VC Git backend.\" :version \"24.1\" :group vc custom-declare-variable vc-git-diff-switches funcall function #[0 \"\\300\\207\" [t] 1] \"String or list of strings specifying switches for Git diff under VC.\\nIf nil, use the value of `vc-diff-switches'. If t, use no switches.\" :type (choice (const :tag \"Unspecified\" nil) (const :tag \"None\" t) (string :tag \"Argument String\") (repeat :tag \"Argument List\" :value (#1=\"\") string)) \"23.1\" vc-git-annotate-switches #[0 \"\\300\\207\" [nil] 1] \"String or list of strings specifying switches for Git blame under VC.\\nIf nil, use the value of `vc-annotate-switches'. If t, use no switches.\" (choice (const :tag \"Unspecified\" nil) (const :tag \"None\" t) (string :tag \"Argument String\") (repeat :tag \"Argument List\" :value (#1#) string)) \"25.1\" vc-git-resolve-conflicts #[0 \"\\300\\207\" [t] 1] \"When non-nil, mark conflicted file as resolved upon saving.\\nThat is performed after all conflict markers in it have been\\nremoved. If the value is `unstage-maybe', and no merge is in\\nprogress, then after the last conflict is resolved, also clear\\nthe staging area.\" (choice (const :tag \"Don't resolve\" nil) (const :tag \"Resolve\" t) (const :tag \"Resolve and maybe unstage all files\" unstage-maybe)) vc-git-program #[0 \"\\300\\207\" [#2=\"git\"] 1 #2#] \"Name of the Git executable (excluding any arguments).\" string vc-git-root-log-format #[0 \"\\300\\207\" [(\"%d%h..: %an %ad %s\" \"^\\\\(?:[*/\\\\| ]+ \\\\)?\\\\(?2: ([^)]+)\\\\)?\\\\(?1:[0-9a-z]+\\\\)..: \\\\(?3:.*?\\\\)[ ]+\\\\(?4:[0-9]\\\\{4\\\\}-[0-9]\\\\{2\\\\}-[0-9]\\\\{2\\\\}\\\\)\" ((1 'log-view-message) (2 'change-log-list nil lax) (3 'change-log-name) (4 'change-log-date)))] 1] \"Git log format for `vc-print-root-log'.\\nThis should be a list (FORMAT REGEXP KEYWORDS), where FORMAT is a\\nformat string (which is passed to \\\"git log\\\" via the argument\\n\\\"--pretty=tformat:FORMAT\\\"), REGEXP is a regular expression\\nmatching the resulting Git log output, and KEYWORDS is a list of\\n`font-lock-keywords' for highlighting the Log View buffer.\" (list string regexp (repeat sexp)) vc-git-commits-coding-system #[0 \"\\300\\207\" [utf-8] 1] \"Default coding system for sending commit log messages to Git.\\n\\nShould be consistent with the Git config value i18n.commitEncoding,\\nand should also be consistent with `locale-coding-system'.\" (coding-system :tag \"Coding system to encode Git commit logs\") vc-git-log-output-coding-system #[0 \"\\300\\207\" [utf-8] 1] \"Default coding system for receiving log output from Git.\\n\\nShould be consistent with the Git config value i18n.logOutputEncoding.\" (coding-system :tag \"Coding system to decode Git log output\") vc-git-grep-template #[0 \"\\300\\207\" [#3=\"git --no-pager grep -n -e -- \"] 1 #3#] \"The default command to run for \\\\[vc-git-grep].\\nThe following place holders should be present in the string:\\n - place to put the options like -i.\\n - file names and wildcards to search.\\n - the regular expression searched for.\" \"27.1\" vc-git-show-stash #[0 \"\\300\\207\" [t] 1] \"How much of the git stash list to show by default.\\nDefault t means all, otherwise an integer specifying the maximum\\nnumber to show. A text button is always shown allowing you to\\ntoggle display of the entire list.\" (choice (const :tag \"All\" t) (integer :tag \"Limit\" :validate (lambda (widget) (unless (>= (widget-value widget) 0) (widget-put widget :error \"Invalid value: must be a non-negative integer\") widget)))) vc-git-revision-complete-only-branches #[0 \"\\300\\207\" [nil] 1] \"Control whether tags are returned by revision completion for Git.\\n\\nWhen non-nil, only branches and remotes will be returned by\\n`vc-git-revision-completion-table'. This is used by various VC\\ncommands when completing branch names. When nil, tags are also\\nincluded in the completions.\" boolean \"28.1\"] 8)" 0 4350 (fontified nil)) :end-point 4433 :exec-time 0.001602 :gc-number 0 :gc-time 0.000000)) ;;ESUP-RESULT-SEPARATOR;;

[jschaf]

I’ve seen this pop up with bytecode incompatibility between Emacs major versions. Maybe try recompiling the elc files?

[condy0919]

I’ve seen this pop up with bytecode incompatibility between Emacs major versions. Maybe try recompiling the elc files?

Thanks, resolved after deleting the .elc files located at /usr/share/. Does it mean that it's a package side bug?

[markgdawson]

I still see this after byte-force-recompile on every path in load-path and restarting emacs. Same backtrace for me also. I'm currently running 26.3

[markgdawson]

Looks like my results buffnr contains some entries without :expression-string key. The code seems to be chocking on these. The esup-results buffer also contains expressions without an :expression-string key. Is this intended?

[jmckitrick]

I just discovered ESUP and tried it today, and got the same result. I’m also running emacs 28 head.

[countvajhula]

This sounds like a really convenient tool! Unfortunately I'm seeing the same issue, on Emacs 27.1.

[jmckitrick]

Any updates on this issue?

[KevOrr]

Looks like *esup-results* contains one entry that looks like

;;ESUP-RESULT-SEPARATOR;;
(list
  )

This gets parsed as nil in esup-read-results, which makes (slot-value result 'expression-string) choke in esup-fontify-results. I've fixed it locally by changing

diff --git a/esup.el b/esup.el
index 737b3aa..0b5fbe1 100644
--- a/esup.el
+++ b/esup.el
@@ -592,7 +592,8 @@ current lexical context."
       (message "at %s" esup-last-result-start-point)
       (unless (eobp)
         (while (setq sep-end-point (esup-next-separator-end-point))
-          (setq results (cons (car (esup-read-result (point))) results))
+          (when-let ((result (car (esup-read-result (point)))))
+            (push result results))
           (setq esup-last-result-start-point sep-end-point)
           (goto-char esup-last-result-start-point))))
     (nreverse results)))

but possibly esup-fontify-results and other functions that consume that list should do nil checking as well. The root cause does seem to do something with bytecode, around the (benchmark-run (eval sexp)) call in esup-child-profile-string.

Edit: Lol should've given https://github.com/jschaf/esup/issues/85#issuecomment-734448917 some more thought. My PATH was messed up and I wasn't running the emacs I thought I was running

[declantsien]

I have similar back-trace(which is not helpful at all) when using esup. But I've found some useful info from *esup-log* buffer

LOG: ERROR(profile-sexp) at ....el:1 with sexp (use-package project :straight (:type built-in) :custom (project-list-file (concat user-emacs-var-directory projects))): error=(void-function use-package)

Then I realized esup didn't load early-init.el file. I have (straight-use-package 'use-package) in early-init.el...

[markasoftware]

I get the same error with Emacs 27.1 on Debian 11 Bullseye.

[anarcat]

seems this is likely a Debian packaging error. i have reported this as a bug against Debian bullseye here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987683

[anarcat]

actually, this looks like a dupe of #54, no?

[jidicula]

This workaround fixes the issue on Emacs 28.1 on macOS https://github.com/jschaf/esup/issues/54#issuecomment-651247749

;; Work around a bug where esup tries to step into the byte-compiled
;; version of `cl-lib', and fails horribly.
(setq esup-depth 0)

[anarcat]

that works, awesome thanks!

[gsingh93]

Is there any workaround other than setting esup-depth to 0? I have various load-file statements to load my own code from other files, and not being able to set the depth prevents me from being able to profile this.

If the issue is with require statements, is there any way to set the depth for require statements but not load-file?

[ispringle]

Both the (setq esup-depth 0) solution and the patch proposed by @KevOrr resolve this for me on Emacs v29. I will say that setting depth to 0 results in much more useful information when using elpaca and configuring most/all settings in use-package statements.