Two fixes for module bug when interleaving threads

Two fixes for module bug when interleaving threads

[Philipp Stephani]

Hi,

I just pushed two fixes for the same bug that appears when
interleaving module calls in separate threads:
cdc632fbe6e149318147a98cccf1b7af191f2ce8 for the release branch and
23974cfa48b9245658667eff81d132b3aecd2618 for master. The intention was
that a simpler and more localized fix should go to the release branch,
the "proper" fix to master. Now I've realized that arguably the
simpler fix is overall better: it's more localized, touches fewer
moving pieces, and is probably not significantly slower (though I
haven't benchmarked it). Any opinions? If people agree, we can
overwrite the fix on master with the fix on the release branch.

Thanks,
Philipp

Re: Two fixes for module bug when interleaving threads

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Fri, 27 Nov 2020 21:57:41 +0100
> 
> I just pushed two fixes for the same bug that appears when
> interleaving module calls in separate threads:
> cdc632fbe6e149318147a98cccf1b7af191f2ce8 for the release branch and
> 23974cfa48b9245658667eff81d132b3aecd2618 for master. The intention was
> that a simpler and more localized fix should go to the release branch,
> the "proper" fix to master. Now I've realized that arguably the
> simpler fix is overall better: it's more localized, touches fewer
> moving pieces, and is probably not significantly slower (though I
> haven't benchmarked it). Any opinions? If people agree, we can
> overwrite the fix on master with the fix on the release branch.

Thanks, but the changes are too significant to go to the release
branch before they are properly tested on master.  With the start of
Emacs 27.2 pretest imminent, I feel it's unsafe to make such changes
there.  So I've reverted the commit on the release branch.

We can revisit this for Emacs 27.3, or if the pretest of Emacs 27.2
takes longer than I expect.

Re: Two fixes for module bug when interleaving threads

[Juri Linkov]

> I just pushed two fixes for the same bug that appears when
> interleaving module calls in separate threads:
> cdc632fbe6e149318147a98cccf1b7af191f2ce8 for the release branch and
> 23974cfa48b9245658667eff81d132b3aecd2618 for master. The intention was
> that a simpler and more localized fix should go to the release branch,
> the "proper" fix to master. Now I've realized that arguably the
> simpler fix is overall better: it's more localized, touches fewer
> moving pieces, and is probably not significantly slower (though I
> haven't benchmarked it). Any opinions? If people agree, we can
> overwrite the fix on master with the fix on the release branch.

Unfortunately, 23974cfa48b9245658667eff81d132b3aecd2618 in master
broke module loading: while loading a module, Emacs prints the
message "Loading (module)..." and hangs, doesn't react to input,
becomes completely unresponsive to C-g.

Here's is the shortest reproducible test case:

M-x package-install RET zmq RET
(load-file "~/.emacs.d/elpa/zmq-20200912.1126/emacs-zmq.so")

It hangs after printing to stderr:

  double free or corruption (!prev)
  Fatal error 6: Aborted

Fortunately, this problem doesn't exist in the 27 release branch.

Re: Two fixes for module bug when interleaving threads

[Philipp Stephani]

Am So., 29. Nov. 2020 um 20:49 Uhr schrieb Juri Linkov <juri@linkov.net>:
>
> > I just pushed two fixes for the same bug that appears when
> > interleaving module calls in separate threads:
> > cdc632fbe6e149318147a98cccf1b7af191f2ce8 for the release branch and
> > 23974cfa48b9245658667eff81d132b3aecd2618 for master. The intention was
> > that a simpler and more localized fix should go to the release branch,
> > the "proper" fix to master. Now I've realized that arguably the
> > simpler fix is overall better: it's more localized, touches fewer
> > moving pieces, and is probably not significantly slower (though I
> > haven't benchmarked it). Any opinions? If people agree, we can
> > overwrite the fix on master with the fix on the release branch.
>
> Unfortunately, 23974cfa48b9245658667eff81d132b3aecd2618 in master
> broke module loading: while loading a module, Emacs prints the
> message "Loading (module)..." and hangs, doesn't react to input,
> becomes completely unresponsive to C-g.
>
> Here's is the shortest reproducible test case:
>
> M-x package-install RET zmq RET
> (load-file "~/.emacs.d/elpa/zmq-20200912.1126/emacs-zmq.so")
>
> It hangs after printing to stderr:
>
>   double free or corruption (!prev)
>   Fatal error 6: Aborted
>

Thanks for the report, fixed with commit
41c338474dd1e086494337fd18ec8828cef1a75c.
(The subtlety here was that this triggered only if a module allocated
more than 512 objects in its initialization function, so the unit
tests didn't catch it.)