bug#59064: 29.0.50; build problem git worktree linked to main worktree (repo)

bug#59064: 29.0.50; build problem git worktree linked to main worktree (repo)

[Gregor Zattler]

Dear Emacs developers,

building Emacs from sources in a detached linked worktree[1]
linked to a main worktree[1] fails, because necessary
-by.el, -wy.el files are not generated as described in
admin/grammars/Makefile for targets `bovine` and `wisent`.
Instead while these files are generated error messages "Args
out of range: "master", 0, 7" are shown and the respective
files are not generated.

Why this is the case, I have no clue.  The respective code
for generating these files is way above my skills.

But I found out that building instead from sources in a
linked worktree linked to a bare repository[1] works as
expected.

This is what I will do from now on, therefore the
aforementioned failure is no problem for me any more.

If there is a bug in the Emacs build system regarding linked
worktrees linked to main worktrees, though, is up to you.

In order to rule out any misconfiguration on my side, I
installed Emacs build dependencies on a minimal installation
of Debian/bullseye, cloned the emacs git repo with a freshly
created and otherwise unconfigured user.  To trigger the
build process this user then issued only "make V=1 -j 1" to
get the most default build process.  All tests were made
with freshly cloned repos respectively freshly generated git
worktrees created from those pristine git repos.

The difference between a linked worktree and its main
worktree is in the .git directory only, as this diff shows:
$ diff -aNurx.git/* emacs2 emacs2-worktree
File emacs2/.git is a directory while file emacs2-worktree/.git is a regular file


While investigating, I learned that the build process embeds
the repository revision into the Emacs binary.  This is the
case if Emacs is build in a linked worktree linked to a bare
repository, as the template from emacs-report-bug shows.

In case of the linked worktree linked to the main worktree
the build process does *not* fail if one removes the .git
file before.  This destroy the link to the repo, though and
the repository version is not embedded in the
resulting binary accordingly.

Why the existence of the .git file disturbs the production
of the grammar files, I have no clue.

If you have further specific questions, I'm happy to help as
far as my very limited knowledge allows.


Thanks for your attention, Gregor

P.S.: This started with a message on help-gnu-emacs:
https://lists.gnu.org/archive/html/help-gnu-emacs/2022-10/msg00860.html
and helpful answers by Eli:
https://lists.gnu.org/archive/html/help-gnu-emacs/2022-11/msg00002.html
and following messages.

[1] In git parlance a
    - "linked worktree" has no .git directory, but a .git
      *file* which's contents points to either a
      - "main worktree" which contains the .git directory,
        (is a git repo with a checked out worktree of its
        own), or a
      - bare repository, which basically is a directory
        containing the contents of a .git dir but without a
        checked out worktree.

bug#59064: 29.0.50; build problem git worktree linked to main worktree (repo)

[Matt Armstrong]

Gregor Zattler <telegraph@gmx.net> writes:

> Dear Emacs developers,
>
> building Emacs from sources in a detached linked worktree[1]
> linked to a main worktree[1] fails, because necessary
> -by.el, -wy.el files are not generated as described in
> admin/grammars/Makefile for targets `bovine` and `wisent`.
> Instead while these files are generated error messages "Args
> out of range: "master", 0, 7" are shown and the respective
> files are not generated.

These sorts of lisp level "Args out of range" errors during the build
are typical of a need to run "make bootstrap" to rebuild much more than
is usually rebuilt.  With respect to lisp compilation the build system
takes a few short cuts for expediency sake, and sometimes requires this
extra help.

See the INSTALL.REPO file in the root of the git tree for more
information about this.

At the extreme, you can tell git to delete all files not under version
control with this command:

    git clean -dfx

This is what I do when I want to get the tree into the same state it
would be if I deleted it entirely and re-cloned it.


> But I found out that building instead from sources in a
> linked worktree linked to a bare repository[1] works as
> expected.

This may have been because re-cloning the worktree was akin to the git
clean command above?

(however, what you say next raises doubts...)


> In order to rule out any misconfiguration on my side, I installed
> Emacs build dependencies on a minimal installation of Debian/bullseye,
> cloned the emacs git repo with a freshly created and otherwise
> unconfigured user.  To trigger the build process this user then issued
> only "make V=1 -j 1" to get the most default build process.  All tests
> were made with freshly cloned repos respectively freshly generated git
> worktrees created from those pristine git repos.
>
> The difference between a linked worktree and its main
> worktree is in the .git directory only, as this diff shows:
> $ diff -aNurx.git/* emacs2 emacs2-worktree
> File emacs2/.git is a directory while file emacs2-worktree/.git is a regular file

Well that is a pretty compelling argument.

I have just created a fresh worktree from a non-bare git repo using:

    git worktree add ../b59064 scratch/matta/master

The "scratch/matta/master" tree is close to the current "master" branch.

Then in the ../b59064 repository, "cat .git" produces:

    gitdir: /home/matt/git/e/emacs/.git/worktrees/b59064

In this directory a clean build works fine, so I have not yet reproduced
the problem.


> While investigating, I learned that the build process embeds
> the repository revision into the Emacs binary.  This is the
> case if Emacs is build in a linked worktree linked to a bare
> repository, as the template from emacs-report-bug shows.

In my case, the built Emacs successfully above figures out the
repository revision.  For example, this is copied out of the buffer
created by M-x report-emacs-bug:

In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.34, cairo version 1.16.0) of 2022-11-05 built on naz
Repository revision: ce917027c69f77b8dd6eb2052b018593f36a393f
Repository branch: scratch/matta/master
System Description: Debian GNU/Linux bookworm/sid

Configured using:
 'configure 'CFLAGS=-Og -g3' 'CXXFLAGS=-Og -g3' --enable-checking=yes
 --enable-check-lisp-object-type --with-pgtk'


> If you have further specific questions, I'm happy to help as
> far as my very limited knowledge allows.

You reproduced this on a fresh Debian/bullseye system, presumably run in
a VM?  I am on Debian Testing, updated about a week ago.  So that is one
difference.

I think the next thing to do is to figure out if either:

a) This can reproduce this on a Debian/testing or Debian/sid system.  Is
it easy for you to spin up a VM to do this?  If so, it would be useful
to know if this is related to the Debian version, as you are likely to
use steps similar to what you've already done.

b) Whether I can reproduce this on a vanilla Debian/bullseye system,
using steps as you've described.  I'm willing to try this, but I don't
have time to do it today.

...or someone else can reproduce it before either of us get to (a) or (b).

bug#59064: 29.0.50; build problem git worktree linked to main worktree (repo)

[Gregor Zattler]

Hi Matt, emacs developers,
* Matt Armstrong <matt@rfc20.org> [2022-11-05; 17:04 -07]:
> Gregor Zattler <telegraph@gmx.net> writes:
>> Dear Emacs developers,
>>
>> building Emacs from sources in a detached linked worktree[1]
>> linked to a main worktree[1] fails, because necessary
>> -by.el, -wy.el files are not generated as described in
>> admin/grammars/Makefile for targets `bovine` and `wisent`.
>> Instead while these files are generated error messages "Args
>> out of range: "master", 0, 7" are shown and the respective
>> files are not generated.
>
> These sorts of lisp level "Args out of range" errors during the build
> are typical of a need to run "make bootstrap" to rebuild much more than
> is usually rebuilt.  With respect to lisp compilation the build system
> takes a few short cuts for expediency sake, and sometimes requires this
> extra help.
>
> See the INSTALL.REPO file in the root of the git tree for more
> information about this.
>
> At the extreme, you can tell git to delete all files not under version
> control with this command:
>
>     git clean -dfx
>
> This is what I do when I want to get the tree into the same state it
> would be if I deleted it entirely and re-cloned it.
>
>
>> But I found out that building instead from sources in a
>> linked worktree linked to a bare repository[1] works as
>> expected.
>
> This may have been because re-cloning the worktree was akin to the git
> clean command above?
>
> (however, what you say next raises doubts...)

All experiments were done in freshly cloned main worktrees,
freshly added linked worktrees from freshly cloned main
worktrees and the like.

>> In order to rule out any misconfiguration on my side, I installed
>> Emacs build dependencies on a minimal installation of Debian/bullseye,
>> cloned the emacs git repo with a freshly created and otherwise
>> unconfigured user.  To trigger the build process this user then issued
>> only "make V=1 -j 1" to get the most default build process.  All tests
>> were made with freshly cloned repos respectively freshly generated git
>> worktrees created from those pristine git repos.
>>
>> The difference between a linked worktree and its main
>> worktree is in the .git directory only, as this diff shows:
>> $ diff -aNurx.git/* emacs2 emacs2-worktree
>> File emacs2/.git is a directory while file emacs2-worktree/.git is a regular file
>
> Well that is a pretty compelling argument.
>
> I have just created a fresh worktree from a non-bare git repo using:
>
>     git worktree add ../b59064 scratch/matta/master
>
> The "scratch/matta/master" tree is close to the current "master" branch.
>
> Then in the ../b59064 repository, "cat .git" produces:
>
>     gitdir: /home/matt/git/e/emacs/.git/worktrees/b59064
>
> In this directory a clean build works fine, so I have not yet reproduced
> the problem.

I now see, I should have showed my command line, I do
*detached* linked worktrees:

git worktree add -d ../emacs2-worktree

This is, because I do not develop, I just want different
builds in order for the possibility to use an older build,
if something goes wrong with a new one.

In a detached linked worktree the build fails as described.

In a not-detached linked worktree produced like so:

git worktree add -f ../emacs2-master master

the build process does *not* fail.

*So this bug report is about detached linked worktrees only.*

(Now it's even more likely this does not bother emacs devs).

>> While investigating, I learned that the build process embeds
>> the repository revision into the Emacs binary.  This is the
>> case if Emacs is build in a linked worktree linked to a bare
>> repository, as the template from emacs-report-bug shows.
>
> In my case, the built Emacs successfully above figures out the
> repository revision.  For example, this is copied out of the buffer
> created by M-x report-emacs-bug:
>
> In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
>  3.24.34, cairo version 1.16.0) of 2022-11-05 built on naz
> Repository revision: ce917027c69f77b8dd6eb2052b018593f36a393f
> Repository branch: scratch/matta/master
> System Description: Debian GNU/Linux bookworm/sid
>
> Configured using:
>  'configure 'CFLAGS=-Og -g3' 'CXXFLAGS=-Og -g3' --enable-checking=yes
>  --enable-check-lisp-object-type --with-pgtk'
>
>
>> If you have further specific questions, I'm happy to help as
>> far as my very limited knowledge allows.
>
> You reproduced this on a fresh Debian/bullseye system, presumably run in
> a VM?

No, this is a Microserver used for backup purposes.

> I am on Debian Testing, updated about a week ago.  So that
> is one difference.
>
> I think the next thing to do is to figure out if either:
>
> a) This can reproduce this on a Debian/testing or Debian/sid system.  Is
> it easy for you to spin up a VM to do this?  If so, it would be useful
> to know if this is related to the Debian version, as you are likely to
> use steps similar to what you've already done.

I used to use VirtualBox, but since this is not part of
Debian stable, I will use this opportunity to learn how to
use KVM.  This will take some time, I will report back.

Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-

bug#59064: 29.0.50; build problem git worktree linked to main worktree (repo)

[Gregor Zattler]

Hi Matt, emacs developers,
* Gregor Zattler <telegraph@gmx.net> [2022-11-06; 12:30 +01]:
> * Matt Armstrong <matt@rfc20.org> [2022-11-05; 17:04 -07]:
>> I think the next thing to do is to figure out if either:
>>
>> a) This can reproduce this on a Debian/testing or Debian/sid system.  Is
>> it easy for you to spin up a VM to do this?  If so, it would be useful
>> to know if this is related to the Debian version, as you are likely to
>> use steps similar to what you've already done.
>
> I used to use VirtualBox, but since this is not part of
> Debian stable, I will use this opportunity to learn how to
> use KVM.  This will take some time, I will report back.

I did so, the results for bookworm are the same:  build in
detached linked worktree linked to main worktree fails,
build in non-detached linked worktree linked to main
worktree succeeds.

Meanwhile on the bullseye server I tested the same with the
sources from emacs-28.2.  There was no failure building
theses in an detached linked worktree, linked to a main
worktree.

I will try to bisect.  But since I have no clue regarding
the build system I only hope that this will not hit other
build failures in between.  This will take days...



Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-

bug#59064: 29.0.50; build problem git worktree linked to main worktree (repo)

[Matt Armstrong]

X-Debbugs-CC: Philip Kaludercic <philipk@posteo.net>

Hi Philip, this bug manifests for Gregor as Emacs build error in a
particular kind of git repository, but it is really a problem with
`vc-git-mode-line-string' caused by a recent commit of yours to
`vc-working-revision'.  Could you take a look?


Gregor Zattler <telegraph@gmx.net> writes:

> I will try to bisect.  But since I have no clue regarding the build
> system I only hope that this will not hit other build failures in
> between.  This will take days...

Gregor, no need to bisect.  Your most recent instructions helped.  This
is not a mysterious problem with the build system, but a simpler one
with a recent regression in Emacs' vc-mode.

The steps to reproduce are simple:

1) In the root directory of an existing Emacs git repository, run this:

      git switch master
      git worktree add -d ../b59064

   Note that the -d is important.  This creates a "detached" work tree
   attached to no branch at all, but just happens to be at the same rev
   as "master".

2) cd ../b59064

3) git status

   Confirm this prints "Not currently on any branch."

3) emacs -Q (using a recent Emacs built on master, not one built in
             this new repository)

3) M-: (setq debug-on-error t)

Edit any file in this repository, I did C-x C-f "INSTALL".  You may then
need to run M-x vc-mode.

You get the following problem in `vc-git-mode-line-string':

Debugger entered--Lisp error: (args-out-of-range "master" 0 7)
  vc-git-mode-line-string("/home/matt/git/e/b59064/admin/grammars/srecode-tem...")
  apply(vc-git-mode-line-string "/home/matt/git/e/b59064/admin/grammars/srecode-tem...")
  vc-call-backend(Git mode-line-string "/home/matt/git/e/b59064/admin/grammars/srecode-tem...")
  vc-mode-line("/home/matt/git/e/b59064/admin/grammars/srecode-tem..." Git)
  vc-refresh-state()
  run-hooks(find-file-hook)
  after-find-file(nil t)
  find-file-noselect-1(#<buffer srecode-template.wy> "~/git/e/b59064/admin/grammars/srecode-template.wy" nil nil "~/git/e/b59064/admin/grammars/srecode-template.wy" (67952095 27))
  find-file-noselect("/home/matt/git/e/b59064/admin/grammars/srecode-tem..." nil nil nil)
  find-file("/home/matt/git/e/b59064/admin/grammars/srecode-tem...")
  dired--find-file(find-file "/home/matt/git/e/b59064/admin/grammars/srecode-tem...")
  dired--find-possibly-alternative-file("/home/matt/git/e/b59064/admin/grammars/srecode-tem...")
  dired-find-file()
  funcall-interactively(dired-find-file)
  call-interactively(dired-find-file nil nil)
  command-execute(dired-find-file)

The `vc-git-mode-line-string' code assumes that if
`vc-git--symbolic-ref` returns nil then `vc-working-revision' must
necessarily return a full hex git rev ID, so it unconditionally performs
the following on that value:

  (substring rev 0 7)

However, Philip Kaludercic's recent commit 307ad210040 changed
`vc-working-revision' to resolve a hex ID to a symbolic revision if
possible, so in this case the function returns "master", causing
`substring' to signal as above.

This is not currently a problem in "normal" git trees because the
following command works in them:

  git symbolic-ref HEAD

...and this is what vc-git-mode-line-string normally uses to construct
the displayed revision used in that line.

In detached worktrees that command fails:

    $ git symbolic-ref HEAD
    fatal: ref HEAD is not a symbolic ref

...yet the following works:

    $ git rev-parse HEAD
    6e5ec085510ccf52ac6cb07c3a1a2778324a1d89

...and from that we can get to a symbolic name (the new code Philip
added to `vc-working-revision'):

    $ git name-rev --no-undefined --name-only 6e5ec085510ccf52ac6cb07c3a1a2778324a1d89
    master

Arguably, `vc-git-mode-line-string' should no longer call
`vc-working-revision' but instead a lower level variation that must
return the hex rev id.  Perhaps?

bug#59064: 29.0.50; build problem git worktree linked to main worktree (repo)

[Philip Kaludercic]

Matt Armstrong <matt@rfc20.org> writes:

> X-Debbugs-CC: Philip Kaludercic <philipk@posteo.net>
>
> Hi Philip, this bug manifests for Gregor as Emacs build error in a
> particular kind of git repository, but it is really a problem with
> `vc-git-mode-line-string' caused by a recent commit of yours to
> `vc-working-revision'.  Could you take a look?

Could this be a duplicate of bug#58709 or bug#59011?  I have argued in
both threads that the commit ought to be reversed.

This particular issue could be resolved by making the code more robust
and removing the hard-coded assumption about how git revisions have to
look like.

> Gregor Zattler <telegraph@gmx.net> writes:
>
>> I will try to bisect.  But since I have no clue regarding the build
>> system I only hope that this will not hit other build failures in
>> between.  This will take days...
>
> Gregor, no need to bisect.  Your most recent instructions helped.  This
> is not a mysterious problem with the build system, but a simpler one
> with a recent regression in Emacs' vc-mode.
>
> The steps to reproduce are simple:
>
> 1) In the root directory of an existing Emacs git repository, run this:
>
>       git switch master
>       git worktree add -d ../b59064
>
>    Note that the -d is important.  This creates a "detached" work tree
>    attached to no branch at all, but just happens to be at the same rev
>    as "master".
>
> 2) cd ../b59064
>
> 3) git status
>
>    Confirm this prints "Not currently on any branch."
>
> 3) emacs -Q (using a recent Emacs built on master, not one built in
>              this new repository)
>
> 3) M-: (setq debug-on-error t)
>
> Edit any file in this repository, I did C-x C-f "INSTALL".  You may then
> need to run M-x vc-mode.
>
> You get the following problem in `vc-git-mode-line-string':
>
> Debugger entered--Lisp error: (args-out-of-range "master" 0 7)
>   vc-git-mode-line-string("/home/matt/git/e/b59064/admin/grammars/srecode-tem...")
>   apply(vc-git-mode-line-string "/home/matt/git/e/b59064/admin/grammars/srecode-tem...")
>   vc-call-backend(Git mode-line-string "/home/matt/git/e/b59064/admin/grammars/srecode-tem...")
>   vc-mode-line("/home/matt/git/e/b59064/admin/grammars/srecode-tem..." Git)
>   vc-refresh-state()
>   run-hooks(find-file-hook)
>   after-find-file(nil t)
>   find-file-noselect-1(#<buffer srecode-template.wy> "~/git/e/b59064/admin/grammars/srecode-template.wy" nil nil "~/git/e/b59064/admin/grammars/srecode-template.wy" (67952095 27))
>   find-file-noselect("/home/matt/git/e/b59064/admin/grammars/srecode-tem..." nil nil nil)
>   find-file("/home/matt/git/e/b59064/admin/grammars/srecode-tem...")
>   dired--find-file(find-file "/home/matt/git/e/b59064/admin/grammars/srecode-tem...")
>   dired--find-possibly-alternative-file("/home/matt/git/e/b59064/admin/grammars/srecode-tem...")
>   dired-find-file()
>   funcall-interactively(dired-find-file)
>   call-interactively(dired-find-file nil nil)
>   command-execute(dired-find-file)
>
> The `vc-git-mode-line-string' code assumes that if
> `vc-git--symbolic-ref` returns nil then `vc-working-revision' must
> necessarily return a full hex git rev ID, so it unconditionally performs
> the following on that value:
>
>   (substring rev 0 7)
>
> However, Philip Kaludercic's recent commit 307ad210040 changed
> `vc-working-revision' to resolve a hex ID to a symbolic revision if
> possible, so in this case the function returns "master", causing
> `substring' to signal as above.
>
> This is not currently a problem in "normal" git trees because the
> following command works in them:
>
>   git symbolic-ref HEAD
>
> ...and this is what vc-git-mode-line-string normally uses to construct
> the displayed revision used in that line.
>
> In detached worktrees that command fails:
>
>     $ git symbolic-ref HEAD
>     fatal: ref HEAD is not a symbolic ref
>
> ...yet the following works:
>
>     $ git rev-parse HEAD
>     6e5ec085510ccf52ac6cb07c3a1a2778324a1d89
>
> ...and from that we can get to a symbolic name (the new code Philip
> added to `vc-working-revision'):
>
>     $ git name-rev --no-undefined --name-only 6e5ec085510ccf52ac6cb07c3a1a2778324a1d89
>     master
>
> Arguably, `vc-git-mode-line-string' should no longer call
> `vc-working-revision' but instead a lower level variation that must
> return the hex rev id.  Perhaps?

bug#59064: 29.0.50; build problem git worktree linked to main worktree (repo)

[Eli Zaretskii]

> Cc: Gregor Zattler <telegraph@gmx.net>, 59064@debbugs.gnu.org
> From: Philip Kaludercic <philipk@posteo.net>
> Date: Sun, 06 Nov 2022 18:38:34 +0000
> 
> Matt Armstrong <matt@rfc20.org> writes:
> 
> > X-Debbugs-CC: Philip Kaludercic <philipk@posteo.net>
> >
> > Hi Philip, this bug manifests for Gregor as Emacs build error in a
> > particular kind of git repository, but it is really a problem with
> > `vc-git-mode-line-string' caused by a recent commit of yours to
> > `vc-working-revision'.  Could you take a look?
> 
> Could this be a duplicate of bug#58709 or bug#59011?  I have argued in
> both threads that the commit ought to be reversed.

Then please go ahead and revert it.

bug#59064: 29.0.50; build problem git worktree linked to main worktree (repo)

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: Gregor Zattler <telegraph@gmx.net>, 59064@debbugs.gnu.org
>> From: Philip Kaludercic <philipk@posteo.net>
>> Date: Sun, 06 Nov 2022 18:38:34 +0000
>> 
>> Matt Armstrong <matt@rfc20.org> writes:
>> 
>> > X-Debbugs-CC: Philip Kaludercic <philipk@posteo.net>
>> >
>> > Hi Philip, this bug manifests for Gregor as Emacs build error in a
>> > particular kind of git repository, but it is really a problem with
>> > `vc-git-mode-line-string' caused by a recent commit of yours to
>> > `vc-working-revision'.  Could you take a look?
>> 
>> Could this be a duplicate of bug#58709 or bug#59011?  I have argued in
>> both threads that the commit ought to be reversed.
>
> Then please go ahead and revert it.

Done.

bug#59064: 29.0.50; build problem git worktree linked to main worktree (repo)

[Matt Armstrong]

Philip Kaludercic <philipk@posteo.net> writes:

>> Then please go ahead and revert it.
>
> Done.

Thanks Philip, I've confirmed that your commit
8fe62b2ab571ba313587e8543006eca03ff36025 on Sun Nov 6 22:18:24 2022
+0100 fixed this issue.

bug#59064: 29.0.50; build problem git worktree linked to main worktree (repo)

[Gregor Zattler]

Hi Matt, Emacs developers,
* Matt Armstrong <matt@rfc20.org> [2022-11-06; 10:17 -08]:
> X-Debbugs-CC: Philip Kaludercic <philipk@posteo.net>
>
> Hi Philip, this bug manifests for Gregor as Emacs build error in a
> particular kind of git repository, but it is really a problem with
> `vc-git-mode-line-string' caused by a recent commit of yours to
> `vc-working-revision'.  Could you take a look?
>
>
> Gregor Zattler <telegraph@gmx.net> writes:
>
>> I will try to bisect.
[...]
> Gregor, no need to bisect.

I already did and it hit on the wrong commit
(44ad42240069d8d82772b0c0ef5ec93c2566ca7e) :-(

> Your most recent instructions helped.

That's good to hear, but I have no idea how you came to your
conclusion :-)

Thanks for your efforts, Gregor
--
 -... --- .-. . -.. ..--.. ...-.-

bug#59064: 29.0.50; build problem git worktree linked to main worktree (repo)

[Matt Armstrong]

Gregor Zattler <telegraph@gmx.net> writes:

>> Your most recent instructions helped.
>
> That's good to hear, but I have no idea how you came to your
> conclusion :-)

...only with a little bit of luck.  I noticed the same lisp level errors
you did when building Emacs in the detached-head repo, and when I
happened to use a recent 29.0.50 Emacs to open one of the .el files in
the same repo I noticed the same error.