Disregard that -- until 29 is out, I just added
>
> (defun python-nav-end-of-statement--bug-override (orig-fn &optional noend)
>   (forward-line 1))
> (advice-add 'python-nav-end-of-statement :around
>    #'python-nav-end-of-statement--bug-override)

to my init.el (from https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58780).
Seems to do the trick for now -- no more lost buffers :-)

On Wed, May 10, 2023 at 5:01 PM James Mazer <mazerj2006@gmail.com> wrote:

> Just confirmed that with an emacs 29.0.90 snap (beta) I'm not seeing the
> lock up. So it appears to be fixed downstream, but would be nice to be able
> to fix in 28 until 29 is actually released :-)
>
>
> On Tue, May 9, 2023 at 9:23 AM James Mazer <mazerj2006@gmail.com> wrote:
>
>> Yes, seems to be the same issue. I just tried replicating his trigger and
>> locked up an emacs window.. here's the backtrace after sigusr2:
>>
>>> Debugger entered--entering a function:
>>> * #f(compiled-function () #<bytecode 0xb893e2c8c539dfa>)()
>>>   syntax-ppss()
>>>   python-nav-end-of-statement()
>>>   python-nav-end-of-block()
>>>   python-info-statement-ends-block-p()
>>>   python-nav--forward-sexp(-1 nil nil)
>>>   python-nav-forward-sexp(-1 nil nil)
>>>   python-nav-backward-sexp()
>>>   python-info-docstring-p((0 nil 390 34 nil nil 0 nil 427 nil nil))
>>>   python-font-lock-syntactic-face-function((0 nil 390 34 nil nil 0 nil
>>> 427 nil nil))
>>>   font-lock-fontify-syntactically-region(180 1700 nil)
>>>   font-lock-default-fontify-region(184 1684 nil)
>>>   font-lock-fontify-region(184 1684)
>>>   #f(compiled-function (fun) #<bytecode
>>> 0x19ba0a4f10e54dbd>)(font-lock-fontify-region)
>>>   jit-lock--run-functions(184 1684)
>>>   jit-lock-fontify-now(184 1684)
>>>   jit-lock-function(184)
>>>   redisplay_internal\ \(C\ function\)()
>>
>>
>> I'll see if I can spin up a version of 29. Been a while since I compiled
>> emacs from scratch... I'm actually surprised that there aren't packages for
>> 28 and 29 more readily available for ubuntu. Not sure what's up with that.
>>
>>
>> On Mon, May 8, 2023 at 9:09 PM Ruijie Yu <ruijie@netyu.xyz> wrote:
>>
>>>
>>> James Mazer <mazerj2006@gmail.com> writes:
>>>
>>> > Don't have time right now to do a custom build, but as sanity check, I
>>> just quickly pulled the 28.2 gnu.org.emacs flatpak and tried that and I get
>>> > exactly the same issue, so it doesn't appear to be specific to the
>>> snap build. I can't find a 29 snap or flatpak to test, though.
>>>
>>> There is also another bug report (closed as fixed on 29), #62794, that I
>>> think is the same as this report and #62325.  In particular, see this
>>> message within that bug report:
>>>
>>> msgid:ZDdE/j6dDbhCw1QF@nicku.org
>>> https://mail.gnu.org/archive/html/bug-gnu-emacs/2023-04/msg00798.html
>>>
>>> What Nick described in #62794 sounds exactly the same as your issue and
>>> Eli's observation: that only _some type(s) of_ python files trigger the
>>> error.  I, as well as Eli, were able to reproduce the issue of #62794
>>> via using the file Nick attached in that message.
>>>
>>> James, can you confirm that Nick's issue on #62794 is exactly the same
>>> as yours in this bug report, and that you can also reproduce the issue
>>> using Nick's attachment from that message?
>>>
>>> And also, if you want to get a version of 29 to test, you can either get
>>> the pretest or clone the code and run "make".  The resultant emacs
>>> binary is located at "src/emacs".  Let me know if this is unclear.
>>>
>>> --
>>> Best,
>>>
>>>
>>> RY
>>>
>>
>>
>> --
>> James Mazer
>> mazerj@gmail.com
>>
>>
>
> --
> James Mazer
> mazerj@gmail.com
>
>

-- 
James Mazer
mazerj@gmail.com