Program exiting with code 3489660927

[dospunk]

My program is crashing and exiting with code 3489660927. I can't find anything about that code online and I'm fairly certain the crash is related to Cursive so does anyone know what it means?

[gyscos]

Thanks for the report!

I'm sorry you're having crashes. Sometimes the ncurses wrapper isn't quite a match with the system library and results in a segfaults, with weird error codes. Do you have a way to reproduce the error? If you can give me some code, I'll fire up a debugger it and see what's going on.

EDIT: I assume you're using the default backend, ncurses? If that's the case, and if you're not running on windows, you can try the termion backend, see if it helps. Though it'd still be interesting to know why it crashes in your configuration... :S

[dospunk]

currently I'm using the pancurses backend. I'll try to reproduce, I've been working on the program some more and haven't gotten the error again but I'll see if I can recreate it.

What I think happened is I have a loop to read from an IRC server and I think that's not playing nicely with Cursive.

[dospunk]

Oh yeah probably should have posted my specs

• OS: Windows 10 Home
• rustc version 1.22.1
• Using the most recent git version of Cursive

[gyscos]

If you run the IRC communication in a separate thread, and it doesn't affect stdin/stdout, it shouldn't interact too much with Cursive. Even if you run it in the same thread (stepping manually the cursive event loop), I don't think there would be any serious issue there: Cursive isn't really time-sensitive (so long pauses between steps should be fine). And even if the IRC code was messing with the input/output, I think the worse case scenario would be a messed-up terminal state, but not a crash. Especially if it's not a clean rust panic. Such crash very likely happen in unsafe or native code, like pdcurses (used by the pancurses backend on windows).

In case it is a rust panic, you can try running export RUST_BACKTRACE=1 before starting the application, and redirect stderr to a file: cargo run 2> error_output, so you can check the file content for any error/backtrace if a crash happens again. But if it's a crash in native code, we'll have to gdb the truth out of it.

[kailando]

I'm having the same exit code in this program: t.py EDIT: I'm using Thonny IDE on Local Python 3. Also, change ".zip" to ".py".

[gyscos]

@kailando Your issue appears unrelated. Your file includes this content:

from turtle import *
import random
import pyautogui
mp=list(pyautogui.position())
print()
color("black")
begin_fill()
end_fill()
turtle.goto(mp)
done()

This repository is about a Rust TUI library, not the python turtle package.

[kailando]

Oh. I thought it was a [turtle] problem, not a Rust problem.

On Mon, Apr 3, 2023 at 4:19 PM Alexandre Bury @.***> wrote:

@kailando https://github.com/kailando Your issue appears unrelated. Your file includes this content:

from turtle import *import randomimport pyautoguimp=list(pyautogui.position())print()color("black")begin_fill()end_fill()turtle.goto(mp)done()

This repository is about a Rust TUI library, not the python turtle package.

— Reply to this email directly, view it on GitHub https://github.com/gyscos/cursive/issues/159#issuecomment-1494994804, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWUL3J7JUHN22S2TAIZTPRTW7M5EZANCNFSM4EG5QYHA . You are receiving this because you were mentioned.Message ID: @.***>

[kailando]

Yes, it was email. I know, why didn't I just put it here? Here's the answer: I didn't know this was going to be sent to GitHub.