bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

[Justin Schell]

[-- Attachment #1: Type: text/plain, Size: 837 bytes --]

Sorry for emailing this list directly, but with emacs build from the latest
commit on `feature/native-comp`, `M-x report-emacs-bug` results in the
error "apply: Wrong type argument: stringp, nil". Enabling `debug-on-error`
doesn't result in a debug session starting when executing that command, so
I'm not sure how to provide any more context for the location that's
throwing the error.

GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin19.6.0, NS appkit-1894.60
Version 10.15.6 (Build 19G2021))
 of 2021-01-06

This version of emacs was built using
https://github.com/jimeh/build-emacs-for-macos from the latest commit on
`feature/native-comp` (33b8ce865fcfd58538ae2d7c3fff04998fcd3330). The
`build-emacs-for-macos` package also applies the fixes from
`feature/native-comp-macos-fixes`.

Let me know if you need more information.

Justin

[-- Attachment #2: Type: text/html, Size: 1047 bytes --]

bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

[Eli Zaretskii]

> From: Justin Schell <justinmschell@gmail.com>
> Date: Wed, 6 Jan 2021 11:16:04 -0800
> 
> Sorry for emailing this list directly, but with emacs build from the latest commit on `feature/native-comp`,
> `M-x report-emacs-bug` results in the error "apply: Wrong type argument: stringp, nil".

No need to apologize, you did the right thing.  Thanks for telling us
about this problem.

bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Justin Schell <justinmschell@gmail.com> writes:

> Sorry for emailing this list directly, but with emacs build from the latest commit on `feature/native-comp`, `M-x
> report-emacs-bug` results in the error "apply: Wrong type argument: stringp, nil". Enabling `debug-on-error` doesn't
> result in a debug session starting when executing that command, so I'm not sure how to provide any more context for the
> location that's throwing the error.

Hi Justin,

thanks for reporting, I swear this is not a trick to cheat on the bug-rate ;)

> GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin19.6.0, NS appkit-1894.60 Version 10.15.6 (Build 19G2021))
>  of 2021-01-06
>
> This version of emacs was built using https://github.com/jimeh/build-emacs-for-macos from the latest commit on
> `feature/native-comp` (33b8ce865fcfd58538ae2d7c3fff04998fcd3330).

That's strange, I just tried a M-x report-emacs-bug on the same commit
on a emacs -Q session and it just works for me.

I'm Ccing Jim so maybe he can try to reproduce on apple-darwin.

> The `build-emacs-for-macos` package also applies the fixes from
> `feature/native-comp-macos-fixes`.

That's odd AFAIK these are not necessary (and if they are we should
probably merge them).

Thanks

  Andrea

bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

[Justin Schell]

> > The `build-emacs-for-macos` package also applies the fixes from
> > `feature/native-comp-macos-fixes`.
>
> That's odd AFAIK these are not necessary (and if they are we should
> probably merge them).

Actually, it looks like `build-emacs-for-macos` no longer does that.
The author just updated the readme a few minutes ago.

I've been trying to isolate the commit that introduced the reported
issue and it appears to be between commits `0f561ee` (issue not
present) and `a3f2373` (issue present).

Justin

bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

[Jim Myhrberg]

Oops, apologies for the confusion, I removed the
feature/native-comp-macos-fixes patch in v0.4.1 (2020-10-29) of
build-emacs-for-macos. But I somehow forgot to remove the CLI flag and
README mentions >_<. I just pushed v0.4.5 which removes all references
to it. More details and links to commits are available in the
changelog here:
https://github.com/jimeh/build-emacs-for-macos/blob/master/CHANGELOG.md

I'm currently building commit 33b8ce8 so I can test `M-x
report-emacs-bug` myself. I'll report back later tonight on it.

bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

[Jim Myhrberg]

I'm afraid I can't reproduce the `M-x report-emacs-bug` issue on
33b8ce8, both with -Q and with my full config. I'm currently on macOS
Big Sur 11.1 (20C69) and Xcode 12.3 (12C33), with all the latest
dependencies from the Brewfile installed. But I have a build of commit
bd693cc (2020-12-25) from macOS Catalina 10.15.7 which does not
exhibit the issue either.

Justin, if your Xcode or Homebrew deps are not fully up to date, I'd
say start there, I've seen odd behavior a few times fixed by simply
updating deps.

> I've been trying to isolate the commit that introduced the reported
> issue and it appears to be between commits `0f561ee` (issue not
> present) and `a3f2373` (issue present).

As far as I can tell commit 0f561ee is from the master branch, so it
does not include any of the changes from the feature/native-comp
branch. I tend to use this as a quick way to see recent commits:
https://github.com/emacs-mirror/emacs/compare/feature/native-comp

And probably of less use in this particular case, but I maintain a
list of feature/native-comp commits which have yielded problem free
builds for me: https://github.com/jimeh/build-emacs-for-macos/issues/6

bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

[Justin Schell]

Thanks for the replies Jim.

> Justin, if your Xcode or Homebrew deps are not fully up to date, I'd
> say start there, I've seen odd behavior a few times fixed by simply
> updating deps.

FWIW, I'm still on Catalina, so there's a potential difference between
our setups (avoiding upgrading to Big Sur for now).

I do also have a pending Xcode update that I hadn't installed because
for some reason it thinks it needs 40GB of free space to install. I
managed to clear the space and am downloading the update now, but
it'll take a while.

I'll test once that's installed and check my Homebrew deps as well.


> > I've been trying to isolate the commit that introduced the reported
> > issue and it appears to be between commits `0f561ee` (issue not
> > present) and `a3f2373` (issue present).
>
> As far as I can tell commit 0f561ee is from the master branch, so it
> does not include any of the changes from the feature/native-comp
> branch. I tend to use this as a quick way to see recent commits:
> https://github.com/emacs-mirror/emacs/compare/feature/native-comp

Sorry if what I said was confusing. I meant that `M-x
report-emacs-bug` works fine as of commit `0f561ee`, but not as of
commit `a3f2373`. There are a few commits in that range, but I haven't
had time to test all of them as the build takes a fair bit of time to
complete.

Also, FWIW, I initially ran into the "Wrong type argument: stringp,
nil" error when `(native-compile-async "~/.emacs.d/elpa" t)` ran. When
I went to use `M-x report-emacs-bug`, I noticed the same error. So,
the underlying issue is presumably something lower-level than either
of those functions themselves.

Justin

bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Justin Schell <justinmschell@gmail.com> writes:

> Thanks for the replies Jim.
>
>> Justin, if your Xcode or Homebrew deps are not fully up to date, I'd
>> say start there, I've seen odd behavior a few times fixed by simply
>> updating deps.
>
> FWIW, I'm still on Catalina, so there's a potential difference between
> our setups (avoiding upgrading to Big Sur for now).
>
> I do also have a pending Xcode update that I hadn't installed because
> for some reason it thinks it needs 40GB of free space to install. I
> managed to clear the space and am downloading the update now, but
> it'll take a while.
>
> I'll test once that's installed and check my Homebrew deps as well.

For completness, I've tried also with a "NATIVE_FULL_AOT=1" bootstrap
but still worked for me on x86_64-linux-gnu.

  Andrea

bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

[Justin Schell]

I'm still seeing the `M-x report-emacs-bug` error: "Wrong type
argument: stringp, nil" issue in builds of `feature/native-comp` made
since updating Xcode and all Homebrew deps this morning.

However, this issue does indeed seem to be caused by something going
awry in the build process on my machine as I just rebuilt from a
commit that I had been using for quite a while (`cb293cf` from
2020-09-10) and I'm now seeing this issue in that build as well. I
still have the build of that commit that I ran in September and `M-x
report-emacs-bug` works fine. I saved the build log and scrolled
through it, but didn't see anything obviously wrong apart from a few
compiler warnings.

Note that I don't see that issue in builds from `master`, so it seems
to be related to a dependency of `feature/native-comp`. I also saved
the build log from a (successful) `master` build. I can try to compare
the logs from the two branches, but I'm not sure if that will be
fruitful.

Any other suggestions for how to debug this issue?

Justin

PS - Something that confused the situation yesterday when I was trying
to isolate the "bad" commit is that due to how Github presents it's
commit logs, specifically with merge commits, I didn't realize that
when I was attempting to build a commit from `feature/native-comp`,
sometimes I was actually building a commit from `master`. Executing a
build with the format from
https://github.com/jimeh/build-emacs-for-macos/issues/6, e.g.,
`./build-emacs-for-macos --git-sha
0f561ee55348ff451600cc6027db5940ee14606f feature/native-comp` is
actually building building a commit from `master` and specifying the
`feature/native-comp` branch name in that command is superfluous.

bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Justin Schell <justinmschell@gmail.com> writes:

> I'm still seeing the `M-x report-emacs-bug` error: "Wrong type
> argument: stringp, nil" issue in builds of `feature/native-comp` made
> since updating Xcode and all Homebrew deps this morning.
>
> However, this issue does indeed seem to be caused by something going
> awry in the build process on my machine as I just rebuilt from a
> commit that I had been using for quite a while (`cb293cf` from
> 2020-09-10) and I'm now seeing this issue in that build as well. I
> still have the build of that commit that I ran in September and `M-x
> report-emacs-bug` works fine. I saved the build log and scrolled
> through it, but didn't see anything obviously wrong apart from a few
> compiler warnings.
>
> Note that I don't see that issue in builds from `master`, so it seems
> to be related to a dependency of `feature/native-comp`. I also saved
> the build log from a (successful) `master` build. I can try to compare
> the logs from the two branches, but I'm not sure if that will be
> fruitful.
>
> Any other suggestions for how to debug this issue?

Hi Justin,

look like there's some odd state that is complicating the investigation.
Have you tried removing the 'eln-cache' folder?  I'm not sure where in
MacOS is, I have it under '~/.emacs.d/eln-cache'.

Also, are we talking about an 'emacs -Q' session correct?

Thanks

  Andrea

bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

[Justin Schell]

> look like there's some odd state that is complicating the investigation.
> Have you tried removing the 'eln-cache' folder?  I'm not sure where in
> MacOS is, I have it under '~/.emacs.d/eln-cache'.

Yes, it still happens after removing the `eln-cache` folder.

> Also, are we talking about an 'emacs -Q' session correct?

Correct.

Justin

bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Justin Schell <justinmschell@gmail.com> writes:

>> look like there's some odd state that is complicating the investigation.
>> Have you tried removing the 'eln-cache' folder?  I'm not sure where in
>> MacOS is, I have it under '~/.emacs.d/eln-cache'.
>
> Yes, it still happens after removing the `eln-cache` folder.
>
>> Also, are we talking about an 'emacs -Q' session correct?
>
> Correct.

I guess the next step for me would be to produce a batch reproducer and
then run it under gdb with a break point in 'wrong_type_argument' to see
where this is going wrong.  It's also bizarre that the Lisp debugger is
not triggered by `toggle-debug-on-error'.

  Andrea

bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

[akrl--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

> Justin Schell <justinmschell@gmail.com> writes:
>
>>> look like there's some odd state that is complicating the investigation.
>>> Have you tried removing the 'eln-cache' folder?  I'm not sure where in
>>> MacOS is, I have it under '~/.emacs.d/eln-cache'.
>>
>> Yes, it still happens after removing the `eln-cache` folder.
>>
>>> Also, are we talking about an 'emacs -Q' session correct?
>>
>> Correct.
>
> I guess the next step for me would be to produce a batch reproducer and
> then run it under gdb with a break point in 'wrong_type_argument' to see
> where this is going wrong.  It's also bizarre that the Lisp debugger is
> not triggered by `toggle-debug-on-error'.
>
>   Andrea

Is this issue still present?  Was it investigated as suggested?

Thanks

  Andrea

bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

[Justin Schell]

> Is this issue still present?  Was it investigated as suggested?

Yes, I just built from the latest `feature/native-comp` commit
(`a8b8d22`) and the issue is still present.

Re: investigation, I was under the impression from your last comment
(below) that you needed to do something to "produce a batch
reproducer". Or did I misunderstand and that's something that I can
do? If so, is there a guide or instructions as I'm not familiar with
how to do that.

> > I guess the next step for me would be to produce a batch reproducer and
> > then run it under gdb with a break point in 'wrong_type_argument' to see
> > where this is going wrong.  It's also bizarre that the Lisp debugger is
> > not triggered by `toggle-debug-on-error'.

Justin

bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

[akrl--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Justin Schell <justinmschell@gmail.com> writes:

>> Is this issue still present?  Was it investigated as suggested?
>
> Yes, I just built from the latest `feature/native-comp` commit
> (`a8b8d22`) and the issue is still present.
>
> Re: investigation, I was under the impression from your last comment
> (below) that you needed to do something to "produce a batch
> reproducer". Or did I misunderstand and that's something that I can
> do? If so, is there a guide or instructions as I'm not familiar with
> how to do that.

I think there's no specific guide other than some basic Elisp knowledge
and some experimentation :)

Perhaps something like this is already sufficient to trigger the error?

emacs -batch -eval '(report-emacs-bug "")'

>> > I guess the next step for me would be to produce a batch reproducer and
>> > then run it under gdb with a break point in 'wrong_type_argument' to see
>> > where this is going wrong.  It's also bizarre that the Lisp debugger is
>> > not triggered by `toggle-debug-on-error'.
>
> Justin

  Andrea

bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

[Justin Schell]

> emacs -batch -eval '(report-emacs-bug "")'

Ah, sorry, I misunderstood as I had never heard of batch mode before.

Simply calling `report-emacs-bug` did not do the trick:
```
[builds (master-)]$
Emacs.app-\[feature-native-comp\]\[2021-01-30\]\[a8b8d22\]\[macOS-10.15\]\[x86_64\].app/Contents/MacOS/Emacs
-batch -eval '(progn (message "foo") (report-emacs-bug "") (message
"bar"))'
foo
Checking for load-path shadows...
Checking for load-path shadows...done
bar
[builds (master-)]$
```

I'll continue to try to figure out how to repro, though.

Justin

bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

[akrl--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Justin Schell <justinmschell@gmail.com> writes:

>> emacs -batch -eval '(report-emacs-bug "")'
>
> Ah, sorry, I misunderstood as I had never heard of batch mode before.
>
> Simply calling `report-emacs-bug` did not do the trick:
> ```
> [builds (master-)]$
> Emacs.app-\[feature-native-comp\]\[2021-01-30\]\[a8b8d22\]\[macOS-10.15\]\[x86_64\].app/Contents/MacOS/Emacs
> -batch -eval '(progn (message "foo") (report-emacs-bug "") (message
> "bar"))'
> foo
> Checking for load-path shadows...
> Checking for load-path shadows...done
> bar
> [builds (master-)]$
> ```
>
> I'll continue to try to figure out how to repro, though.
>
> Justin

Hi Justin,

one could also place the breackpoint from gdb for an interactive
session, is just a little more annoying if one want to re-run multiple
times while debugging.

BTW dumb question: the issue is present also running "emacs -Q" right?

Thanks

  Andrea

bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

[Justin Schell]

> BTW dumb question: the issue is present also running "emacs -Q" right?

Yes.

> one could also place the breackpoint from gdb for an interactive
> session, is just a little more annoying if one want to re-run multiple
> times while debugging.

Trying to do that, but I have no idea what I'm doing with gdb. The
following doesn't seem to do anything useful. It does seem to run an
emacs process, but there's no window that comes up for me to interact
with and nothing else seems to happen:
```
[builds (master %=)]$ gdb
Emacs.app-\[feature-native-comp\]\[2021-01-30\]\[a8b8d22\]\[macOS-10.15\]\[x86_64\].app/Contents/MacOS/Emacs
GNU gdb (GDB) 10.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin19.6.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from
Emacs.app-[feature-native-comp][2021-01-30][a8b8d22][macOS-10.15][x86_64].app/Contents/MacOS/Emacs...
(No debugging symbols found in
Emacs.app-[feature-native-comp][2021-01-30][a8b8d22][macOS-10.15][x86_64].app/Contents/MacOS/Emacs)
(gdb)
(gdb) catch throw
Catchpoint 1 (throw)
(gdb) run -Q
Starting program:
/Users/jschell/src_ext/build-emacs-for-macos/builds/Emacs.app-[feature-native-comp][2021-01-30][a8b8d22][macOS-10.15][x86_64].app/Contents/MacOS/Emacs
-Q
[New Thread 0x1b03 of process 4105]
[New Thread 0x2303 of process 4105]
```

I've also tried with `-nw` with similar results.

Am I going to have to build with debug symbols to do anything useful?
I can try to figure that out, but that's not something that I've done
either.

Justin

bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

[akrl--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Justin Schell <justinmschell@gmail.com> writes:

>> BTW dumb question: the issue is present also running "emacs -Q" right?
>
> Yes.
>
>> one could also place the breackpoint from gdb for an interactive
>> session, is just a little more annoying if one want to re-run multiple
>> times while debugging.
>
> Trying to do that, but I have no idea what I'm doing with gdb. The
> following doesn't seem to do anything useful. It does seem to run an
> emacs process, but there's no window that comes up for me to interact
> with and nothing else seems to happen:

I think the idea would be ~ to:

- compile with debug symbols

- start gdb loading emacs

- source .gdbinit

- add a breakpoint in 'wrong_type_argument'

- run Emacs and let the error happen

- At this point gdb should take control and you should be able to type
  'bt' to obtain and report the backtrace

Thanks

  Andrea

bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

[Justin Schell]

> I think the idea would be ~ to:
>
> - compile with debug symbols
>
> - start gdb loading emacs
>
> - source .gdbinit
>
> - add a breakpoint in 'wrong_type_argument'
>
> - run Emacs and let the error happen
>
> - At this point gdb should take control and you should be able to type
>   'bt' to obtain and report the backtrace

Thanks, I'll give that a go soon.

Justin

bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

[Justin Schell]

> I think the idea would be ~ to:
>
> - compile with debug symbols
>
> - start gdb loading emacs
>
> - source .gdbinit
>
> - add a breakpoint in 'wrong_type_argument'
>
> - run Emacs and let the error happen
>
> - At this point gdb should take control and you should be able to type
>   'bt' to obtain and report the backtrace

Hi Andrea,

So, I was able to build emacs with debug symbols and run via gdb as
directed above, but unfortunately, gdb doesn't hit the breakpoint when
I run `M-x report-emacs-bug`. gdb does break quite a few times (770
times, to be exact) on `wrong_type_argument` during startup, though. I
looked at the emacs source a bit to try to put a breakpoint somewhere
that would be more fruitful, but I didn't really see where I would do
so.

I did a screen capture of my reproducing the issue on this thread.
Perhaps you could take a look and would have an idea for what I might
be doing wrong or what to try next. See
https://github.com/schellj/emacs-native-comp-debug/blob/wrong-type-argument/emacs-native-comp-wrong-type-argument.mov

Thanks,
Justin

bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

[Justin Schell]

Also, here are backtraces from the first two times that the
`wrong_type_argument` breakpoint was hit during startup:
```
Thread 2 hit Breakpoint 2, wrong_type_argument (predicate=XIL(0xd9),
value=make_fixnum(35183774783506)) at data.c:143
143   xsignal2 (Qwrong_type_argument, predicate, value);
(gdb) bt
#0  wrong_type_argument (predicate=XIL(0xd9),
value=make_fixnum(35183774783506)) at data.c:143
#1  0x0000000100222b2e in dump_discard_mem (mem=0x145bcca3d,
size=5464967736) at pdumper.c:4650
#2  0x00007ffeefbfed20 in ?? ()
#3  0x0000000145bfd225 in ?? ()
#4  0x00007ffeefbfed10 in ?? ()
#5  0x000000010021f5a9 in HASH_VALUE (h=0x145bcca3d, idx=5464967736)
at ./lisp.h:2380
#6  0x0000000145bcca38 in ?? ()
#7  0x0000000145bcca3d in ?? ()
#8  0x00007ffeefbfed40 in ?? ()
#9  0x000000010021a271 in thaw_hash_tables () at pdumper.c:5671
Backtrace stopped: frame did not save the PC
(gdb) c
Continuing.

Thread 2 hit Breakpoint 2, wrong_type_argument (predicate=XIL(0x447),
value=XIL(0x145bcca38)) at data.c:143
143   xsignal2 (Qwrong_type_argument, predicate, value);
(gdb) bt
#0  wrong_type_argument (predicate=XIL(0x447), value=XIL(0x145bcca38))
at data.c:143
#1  0x0000000100222b2e in dump_discard_mem (mem=0x145b7e085,
size=5464645760) at pdumper.c:4650
#2  0xfffffffffffffffe in ?? ()
#3  0x0000000145bfd225 in ?? ()
#4  0x00007ffeefbfed10 in ?? ()
#5  0x000000010021f5a9 in HASH_VALUE (h=0x145b7e085, idx=5464645760)
at ./lisp.h:2380
#6  0x0000000145b7e080 in ?? ()
#7  0x0000000145b7e085 in ?? ()
#8  0x00007ffeefbfed40 in ?? ()
#9  0x000000010021a271 in thaw_hash_tables () at pdumper.c:5671
Backtrace stopped: frame did not save the PC
```

On Mon, Feb 8, 2021 at 12:49 PM Justin Schell <justinmschell@gmail.com> wrote:
>
> > I think the idea would be ~ to:
> >
> > - compile with debug symbols
> >
> > - start gdb loading emacs
> >
> > - source .gdbinit
> >
> > - add a breakpoint in 'wrong_type_argument'
> >
> > - run Emacs and let the error happen
> >
> > - At this point gdb should take control and you should be able to type
> >   'bt' to obtain and report the backtrace
>
> Hi Andrea,
>
> So, I was able to build emacs with debug symbols and run via gdb as
> directed above, but unfortunately, gdb doesn't hit the breakpoint when
> I run `M-x report-emacs-bug`. gdb does break quite a few times (770
> times, to be exact) on `wrong_type_argument` during startup, though. I
> looked at the emacs source a bit to try to put a breakpoint somewhere
> that would be more fruitful, but I didn't really see where I would do
> so.
>
> I did a screen capture of my reproducing the issue on this thread.
> Perhaps you could take a look and would have an idea for what I might
> be doing wrong or what to try next. See
> https://github.com/schellj/emacs-native-comp-debug/blob/wrong-type-argument/emacs-native-comp-wrong-type-argument.mov
>
> Thanks,
> Justin

bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Justin Schell <justinmschell@gmail.com> writes:

>> I think the idea would be ~ to:
>>
>> - compile with debug symbols
>>
>> - start gdb loading emacs
>>
>> - source .gdbinit
>>
>> - add a breakpoint in 'wrong_type_argument'
>>
>> - run Emacs and let the error happen
>>
>> - At this point gdb should take control and you should be able to type
>>   'bt' to obtain and report the backtrace
>
> Hi Andrea,
>
> So, I was able to build emacs with debug symbols and run via gdb as
> directed above, but unfortunately, gdb doesn't hit the breakpoint when
> I run `M-x report-emacs-bug`. gdb does break quite a few times (770
> times, to be exact) on `wrong_type_argument` during startup, though. I
> looked at the emacs source a bit to try to put a breakpoint somewhere
> that would be more fruitful, but I didn't really see where I would do
> so.

I think we are likely to be interested only in the last occurence.  You
can ignore the breakpoint 769 times to see what's going on:

(gdb) b wrong_type_argument
Breakpoint 5 at 0x58a0a2: file data.c, line 143.
(gdb) ignore 5 769
Will ignore next 769 crossings of breakpoint 5.
(gdb) run

Thanks

  Andrea

bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

[Justin Schell]

> I think we are likely to be interested only in the last occurence.  You
> can ignore the breakpoint 769 times to see what's going on:
>
> (gdb) b wrong_type_argument
> Breakpoint 5 at 0x58a0a2: file data.c, line 143.
> (gdb) ignore 5 769
> Will ignore next 769 crossings of breakpoint 5.
> (gdb) run

I apparently double-counted before; it was actually only 385
occurrences, but I was able to actually get it to break after
executing `M-x report-emacs-bug` this time. I can try to debug this
later, but I imagine you'll have an idea of what's going on this time.
```
[builds (master *%=)]$ gdb
Emacs.app-\[feature-native-comp\]\[2021-02-03\]\[1f626e9\]\[macOS-10.15\]\[x86_64\].app/Contents/MacOS/Emacs
GNU gdb (GDB) 10.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin19.6.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from
Emacs.app-[feature-native-comp][2021-02-03][1f626e9][macOS-10.15][x86_64].app/Contents/MacOS/Emacs...
(gdb) source ../sources/emacs-mirror-emacs-1f626e9/src/.gdbinit
Warning: /Users/jschell/src_ext/build-emacs-for-macos/builds/../lwlib:
No such file or directory.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not
from terminal]
DISPLAY = /private/tmp/com.apple.launchd.tuA6638B13/org.macosforge.xquartz:0
TERM = xterm-256color
Breakpoint 1 at 0x100156df0: terminate_due_to_signal. (2 locations)
(gdb) b wrong_type_argument
Breakpoint 2 at 0x100222bc5: wrong_type_argument. (2 locations)
(gdb) set startup-with-shell off
(gdb) ignore 2 384
Will ignore next 384 crossings of breakpoint 2.
(gdb) run -Q
Starting program:
/Users/jschell/src_ext/build-emacs-for-macos/builds/Emacs.app-[feature-native-comp][2021-02-03][1f626e9][macOS-10.15][x86_64].app/Contents/MacOS/Emacs
-Q
[New Thread 0x2603 of process 49252]
[New Thread 0x2303 of process 49252]
warning: unhandled dyld version (16)

Thread 2 hit Breakpoint 2, wrong_type_argument (predicate=XIL(0x9),
value=XIL(0x145813f50)) at data.c:143
143   xsignal2 (Qwrong_type_argument, predicate, value);
(gdb) bt
#0  wrong_type_argument (predicate=XIL(0x9), value=XIL(0x145813f50))
at data.c:143
#1  0x0000000100222b2e in dump_discard_mem (mem=0x14581345d,
size=5461062744) at pdumper.c:4650
#2  0xfffffffffffffffe in ?? ()
#3  0x00000001463fd225 in ?? ()
#4  0x00007ffeefbfed10 in ?? ()
#5  0x000000010021f5a9 in HASH_VALUE (h=0x14581345d, idx=5461062744)
at ./lisp.h:2380
#6  0x0000000145813458 in ?? ()
#7  0x000000014581345d in ?? ()
#8  0x00007ffeefbfed40 in ?? ()
#9  0x000000010021a271 in thaw_hash_tables () at pdumper.c:5671
Backtrace stopped: frame did not save the PC
(gdb) c
Continuing.
[New Thread 0x1c03 of process 49252]
[New Thread 0x1d03 of process 49252]
[New Thread 0x1e03 of process 49252]
[New Thread 0x1f03 of process 49252]
[New Thread 0x2003 of process 49252]
[New Thread 0x252b of process 49252]

Thread 2 hit Breakpoint 2, 0x00000001003cb6a0 in ?? ()
(gdb) bt
#0  0x00000001003cb6a0 in ?? ()
#1  0x00000001001ba3cd in Ffind_file_name_handler (filename=XIL(0),
operation=make_fixnum(18049580734087168))
    at fileio.c:304
#2  0x01007ffe00000002 in ?? ()
#3  0x0000000000000000 in ?? ()
[New Thread 0x2657 of process 49252]

Lisp Backtrace:
"native-compile-setup-environment-variables" (0xefbfa558)
"apply" (0xefbfa808)
"native--compile-async" (0xefbfaf50)
"defalias" (0xefbfb150)
"require" (0xefbfbb60)
"byte-code" (0xefbfc340)
"require" (0xefbfcd50)
"byte-code" (0xefbfd470)
"command-execute" (0xefbfdf20)
"execute-extended-command" (0xefbfe2a0)
"funcall-interactively" (0xefbfe298)
"command-execute" (0xefbfecd0)
(gdb) c
Continuing.
[New Thread 0x210f of process 49252]
```

bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Justin Schell <justinmschell@gmail.com> writes:

>> I think we are likely to be interested only in the last occurence.  You
>> can ignore the breakpoint 769 times to see what's going on:
>>
>> (gdb) b wrong_type_argument
>> Breakpoint 5 at 0x58a0a2: file data.c, line 143.
>> (gdb) ignore 5 769
>> Will ignore next 769 crossings of breakpoint 5.
>> (gdb) run
>
> I apparently double-counted before; it was actually only 385
> occurrences, but I was able to actually get it to break after
> executing `M-x report-emacs-bug` this time. I can try to debug this
> later, but I imagine you'll have an idea of what's going on this time.

[...]

> Thread 2 hit Breakpoint 2, wrong_type_argument (predicate=XIL(0x9),
> value=XIL(0x145813f50)) at data.c:143
> 143   xsignal2 (Qwrong_type_argument, predicate, value);
> (gdb) bt
> #0  wrong_type_argument (predicate=XIL(0x9), value=XIL(0x145813f50))
> at data.c:143
> #1  0x0000000100222b2e in dump_discard_mem (mem=0x14581345d,
> size=5461062744) at pdumper.c:4650
> #2  0xfffffffffffffffe in ?? ()
> #3  0x00000001463fd225 in ?? ()
> #4  0x00007ffeefbfed10 in ?? ()
> #5  0x000000010021f5a9 in HASH_VALUE (h=0x14581345d, idx=5461062744)
> at ./lisp.h:2380
> #6  0x0000000145813458 in ?? ()
> #7  0x000000014581345d in ?? ()
> #8  0x00007ffeefbfed40 in ?? ()
> #9  0x000000010021a271 in thaw_hash_tables () at pdumper.c:5671
> Backtrace stopped: frame did not save the PC
> (gdb) c
> Continuing.
> [New Thread 0x1c03 of process 49252]
> [New Thread 0x1d03 of process 49252]
> [New Thread 0x1e03 of process 49252]
> [New Thread 0x1f03 of process 49252]
> [New Thread 0x2003 of process 49252]
> [New Thread 0x252b of process 49252]
>
> Thread 2 hit Breakpoint 2, 0x00000001003cb6a0 in ?? ()
> (gdb) bt
> #0  0x00000001003cb6a0 in ?? ()
> #1  0x00000001001ba3cd in Ffind_file_name_handler (filename=XIL(0),
> operation=make_fixnum(18049580734087168))
>     at fileio.c:304
> #2  0x01007ffe00000002 in ?? ()
> #3  0x0000000000000000 in ?? ()
> [New Thread 0x2657 of process 49252]
>
> Lisp Backtrace:
> "native-compile-setup-environment-variables" (0xefbfa558)

Okay this is odd, in feature/native-comp we don't have a function called
`native-compile-setup-environment-variables' so I guess this is coming
from somewhere else, look like the problem is there.

Do you know where this function is coming from?

  Andrea

> "apply" (0xefbfa808)
> "native--compile-async" (0xefbfaf50)
> "defalias" (0xefbfb150)
> "require" (0xefbfbb60)
> "byte-code" (0xefbfc340)
> "require" (0xefbfcd50)
> "byte-code" (0xefbfd470)
> "command-execute" (0xefbfdf20)
> "execute-extended-command" (0xefbfe2a0)
> "funcall-interactively" (0xefbfe298)
> "command-execute" (0xefbfecd0)
> (gdb) c
> Continuing.
> [New Thread 0x210f of process 49252]
> ```
>

-- 
akrl@sdf.org

bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

[Justin Schell]

> > Thread 2 hit Breakpoint 2, wrong_type_argument (predicate=XIL(0x9),
> > value=XIL(0x145813f50)) at data.c:143
> > 143   xsignal2 (Qwrong_type_argument, predicate, value);
> > (gdb) bt
> > #0  wrong_type_argument (predicate=XIL(0x9), value=XIL(0x145813f50))
> > at data.c:143
> > #1  0x0000000100222b2e in dump_discard_mem (mem=0x14581345d,
> > size=5461062744) at pdumper.c:4650
> > #2  0xfffffffffffffffe in ?? ()
> > #3  0x00000001463fd225 in ?? ()
> > #4  0x00007ffeefbfed10 in ?? ()
> > #5  0x000000010021f5a9 in HASH_VALUE (h=0x14581345d, idx=5461062744)
> > at ./lisp.h:2380
> > #6  0x0000000145813458 in ?? ()
> > #7  0x000000014581345d in ?? ()
> > #8  0x00007ffeefbfed40 in ?? ()
> > #9  0x000000010021a271 in thaw_hash_tables () at pdumper.c:5671
> > Backtrace stopped: frame did not save the PC
> > (gdb) c
> > Continuing.
> > [New Thread 0x1c03 of process 49252]
> > [New Thread 0x1d03 of process 49252]
> > [New Thread 0x1e03 of process 49252]
> > [New Thread 0x1f03 of process 49252]
> > [New Thread 0x2003 of process 49252]
> > [New Thread 0x252b of process 49252]
> >
> > Thread 2 hit Breakpoint 2, 0x00000001003cb6a0 in ?? ()
> > (gdb) bt
> > #0  0x00000001003cb6a0 in ?? ()
> > #1  0x00000001001ba3cd in Ffind_file_name_handler (filename=XIL(0),
> > operation=make_fixnum(18049580734087168))
> >     at fileio.c:304
> > #2  0x01007ffe00000002 in ?? ()
> > #3  0x0000000000000000 in ?? ()
> > [New Thread 0x2657 of process 49252]
> >
> > Lisp Backtrace:
> > "native-compile-setup-environment-variables" (0xefbfa558)
>
> Okay this is odd, in feature/native-comp we don't have a function called
> `native-compile-setup-environment-variables' so I guess this is coming
> from somewhere else, look like the problem is there.
>
> Do you know where this function is coming from?

Yeah, looks like it's patched in by build-emacs-for-macos:
https://github.com/jimeh/build-emacs-for-macos/blob/master/patches/native-comp-env-setup.patch#L10

Jim, if you're still following this thread, would you be able to take a look?

Justin

bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

[Jim Myhrberg]

The TL;DR for the patch; It is essentially a horrible and hacky first
draft I threw together to set the LIBRARY_PATH environment variable to
point at the GCC directories that my build script copies into the
macOS "Emacs.app" bundle to make it fully self-contained. The
LIBRARY_PATH environment variable needs to be set to point at the
"embedded" GCC directories before any native compilation starts, which
is currently done through the horrible advice-add/remove stuff.

Justin, I've not had any reports of similar issues to yours, but I
have just managed to reproduce the error by breaking my Emacs.app
bundle in a very specific way. What folders do you have under
"Emacs.app/Contents/MacOS/lib/gcc" in your app bundle? There's
supposed to be a folder called "10". I reproduced the issue by
renaming my "10" folder so it no longer matches regexp "^[0-9]+$". If
you have something else, it's time to debug how that happened and
where my build script went wrong.

Either way this seems to fall pretty much into my area, so I've
created a GitHub issue to track improvements to the patch, and I'm
happy to continue discussions there:
https://github.com/jimeh/build-emacs-for-macos/issues/29

Andrea, I've actually been meaning to ask you for months if you might
be able suggest a better approach for the patch, and I'd greatly
appreciate any time you can spare :)

And finally, I'm sorry for all the headache which was most likely
caused by my hacky patch :(

On Tue, Feb 9, 2021 at 9:34 PM Justin Schell <justinmschell@gmail.com> wrote:
>
> > > Thread 2 hit Breakpoint 2, wrong_type_argument (predicate=XIL(0x9),
> > > value=XIL(0x145813f50)) at data.c:143
> > > 143   xsignal2 (Qwrong_type_argument, predicate, value);
> > > (gdb) bt
> > > #0  wrong_type_argument (predicate=XIL(0x9), value=XIL(0x145813f50))
> > > at data.c:143
> > > #1  0x0000000100222b2e in dump_discard_mem (mem=0x14581345d,
> > > size=5461062744) at pdumper.c:4650
> > > #2  0xfffffffffffffffe in ?? ()
> > > #3  0x00000001463fd225 in ?? ()
> > > #4  0x00007ffeefbfed10 in ?? ()
> > > #5  0x000000010021f5a9 in HASH_VALUE (h=0x14581345d, idx=5461062744)
> > > at ./lisp.h:2380
> > > #6  0x0000000145813458 in ?? ()
> > > #7  0x000000014581345d in ?? ()
> > > #8  0x00007ffeefbfed40 in ?? ()
> > > #9  0x000000010021a271 in thaw_hash_tables () at pdumper.c:5671
> > > Backtrace stopped: frame did not save the PC
> > > (gdb) c
> > > Continuing.
> > > [New Thread 0x1c03 of process 49252]
> > > [New Thread 0x1d03 of process 49252]
> > > [New Thread 0x1e03 of process 49252]
> > > [New Thread 0x1f03 of process 49252]
> > > [New Thread 0x2003 of process 49252]
> > > [New Thread 0x252b of process 49252]
> > >
> > > Thread 2 hit Breakpoint 2, 0x00000001003cb6a0 in ?? ()
> > > (gdb) bt
> > > #0  0x00000001003cb6a0 in ?? ()
> > > #1  0x00000001001ba3cd in Ffind_file_name_handler (filename=XIL(0),
> > > operation=make_fixnum(18049580734087168))
> > >     at fileio.c:304
> > > #2  0x01007ffe00000002 in ?? ()
> > > #3  0x0000000000000000 in ?? ()
> > > [New Thread 0x2657 of process 49252]
> > >
> > > Lisp Backtrace:
> > > "native-compile-setup-environment-variables" (0xefbfa558)
> >
> > Okay this is odd, in feature/native-comp we don't have a function called
> > `native-compile-setup-environment-variables' so I guess this is coming
> > from somewhere else, look like the problem is there.
> >
> > Do you know where this function is coming from?
>
> Yeah, looks like it's patched in by build-emacs-for-macos:
> https://github.com/jimeh/build-emacs-for-macos/blob/master/patches/native-comp-env-setup.patch#L10
>
> Jim, if you're still following this thread, would you be able to take a look?
>
> Justin

bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

[Justin Schell]

> Justin, I've not had any reports of similar issues to yours, but I
> have just managed to reproduce the error by breaking my Emacs.app
> bundle in a very specific way. What folders do you have under
> "Emacs.app/Contents/MacOS/lib/gcc" in your app bundle? There's
> supposed to be a folder called "10". I reproduced the issue by
> renaming my "10" folder so it no longer matches regexp "^[0-9]+$". If
> you have something else, it's time to debug how that happened and
> where my build script went wrong.

Jim, I do have a `Emacs.app/Contents/MacOS/lib/gcc/10` directory.

However, I seem to have found the issue. Since I had been doing builds
from several different branches and commits, I had been naming the
base-dir of the Emacs.app in concert with the name of the build
tarball that `build-emacs-for-macos` produces to keep track of which
was which. E.g.,
'Emacs.app-[feature-native-comp][2021-02-03][1f626e9][macOS-10.15][x86_64].app'.
If I rename that to just 'Emacs.app', I can no longer reproduce the
`M-x report-emacs-bug` "Wrong type argument: stringp, nil" error.
Thus, somewhere the `native-compile-setup-environment-variables` patch
code doesn't seem to handle that sort of invocation-dir name. I don't
have time to debug exactly where right now, but let me know if you
need anything else.

Glad that it seems that we've found the root issue (at least
approximately). Thanks for the help, all.

Justin

bug#45701: 28.0.50; [feature/native-comp] (33b8ce8) `M-x report-emacs-bug` error: "Wrong type argument: stringp, nil"

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Jim Myhrberg <contact@jimeh.me> writes:

> The TL;DR for the patch; It is essentially a horrible and hacky first
> draft I threw together to set the LIBRARY_PATH environment variable to
> point at the GCC directories that my build script copies into the
> macOS "Emacs.app" bundle to make it fully self-contained. The
> LIBRARY_PATH environment variable needs to be set to point at the
> "embedded" GCC directories before any native compilation starts, which
> is currently done through the horrible advice-add/remove stuff.
>
> Justin, I've not had any reports of similar issues to yours, but I
> have just managed to reproduce the error by breaking my Emacs.app
> bundle in a very specific way. What folders do you have under
> "Emacs.app/Contents/MacOS/lib/gcc" in your app bundle? There's
> supposed to be a folder called "10". I reproduced the issue by
> renaming my "10" folder so it no longer matches regexp "^[0-9]+$". If
> you have something else, it's time to debug how that happened and
> where my build script went wrong.
>
> Either way this seems to fall pretty much into my area, so I've
> created a GitHub issue to track improvements to the patch, and I'm
> happy to continue discussions there:
> https://github.com/jimeh/build-emacs-for-macos/issues/29
>
> Andrea, I've actually been meaning to ask you for months if you might
> be able suggest a better approach for the patch, and I'd greatly
> appreciate any time you can spare :)

Hi Jim,

sure I'll try to have a look and come with a comment on that.

As there's a specific issue on the correct repo I'm closing this.

Thanks

  Andrea