Subject: Re: bug#14473: 24.3; emacs locks up when eshell attempts to display a dialog

From: Joseph Mingrone <[email-masked]>
Date: Mon, 07 Oct 2019 15:53:51 -0300

Stefan Kangas <[email-masked]> writes:

> Joseph Mingrone <[email-masked]> writes:

>> It's still a problem (26.3 and 2019-09-15 master-branch build) in that the dialog is not displayed, but the Emacs process no longer consumes 100% CPU.

> Thanks for reporting back.

>> Here is a simple recipe to reproduce the problem.  It assumes the FreeBSD ports tree is installed in the default location, which is /usr/ports.

> Can you think of any way to reproduce this if you are not using
> FreeBSD?  Is there some particular command run by "make config" that
> makes eshell freeze for example?  It seems to me that very few Emacs
> developers are using FreeBSD, and I personally don't have access to
> any FreeBSD systems for debugging.

I would guess any GNU/Linux command that also presents these curses
dialogs would have problems.  If you or any Emacs developer wants a
FreeBSD shell account, I can provide one.

https://invisible-island.net/dialog/dialog-figures.html

To be clear, it seems like less of a freeze now and more like an
inability to display the dialog and the point becomes lost requiring
users to kill eshell.  So, it is much less severe of a problem than in
the past.

>> Instead of the dialog displaying, eshell becomes unusable (blank screen and no keys will return the prompt).  Trying to exit by hitting TAB/Enter reports

>> Completion function pcomplete-completions-at-point uses a deprecated calling convention
>> Warning: pcomplete-completions-at-point failed to return valid completion data!

>> You can switch buffers and kill the eshell process now though.

> What happens if you run M-x toggle-debug-on-error before trying to
> reproduce?  Do you then get a backtrace?

There is no backtrace.

Regards,

Joseph