bug#69872: 29.2; Async native compilation of seq.el test uses up resources and hangs

[Andrea Corallo]

merge 69872 67883
thanks

Andrea Corallo <acorallo@gnu.org> writes:

> Jon Levin via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs@gnu.org> writes:
>
>> When I update my installed packages on some version of emacs which
>> is build with native-compilation enabled, most times I end up
>> having to kill emacs and restart it in order to sidestep a problem
>> where a single emacs process, seemingly running a compilation step
>> (I think) uses 100% of a single virtual core and never completes.
>>
>> This is the process responsible:
>>
>>   mhcat 12800 6874 99 09:10 pts/96 00:10:41 /usr/bin/emacs
>> -no-comp-spawn -Q --batch --eval (setq w32-disable-abort-dialog t)
>> -l /tmp/emacs-async-comp-seq-tests-znp6r0.el
>>
>> I am not sure how to go about reproducing this problem from a
>> standing start (emacs -Q) because this seems to be part of an
>> otherwise opaque series of steps, and I'm not sure how it starts.
>>
>> Perhaps the author of seq.el can help me put together such a test.
>>
>> This is not a new problem, but I noticed that there is a plan to
>> make native-comp part of the default emacs build, to which I have
>> no objection, but feel that my experience is a data point which
>> should not be overlooked. I usually end up building a
>> non-native-comp version of emacs as a daily driver (I am lucky
>> enough to have systems powerful enough that I notice no difference
>> in performance with or without native-compilation enabled - aside
>> from the initial compilation phases which in the case of
>> native-comp, which are a minor inconvenience).
>>
>> Thanks!
>
> Hi Jon,
>
> I can reproduce on master with:
>
> ./src/emacs -batch -l comp -f batch-native-compile 
> test/lisp/emacs-lisp/seq-tests.el
>
> I'll try to have look.

Okay after reducing it I believe it's a duplicate of 67883 so I'm
merging them.

  Andrea