Re: Two fixes for module bug when interleaving threads

[Philipp Stephani <p.stephani2@gmail.com>]

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.)