Segfault/stack smashing with tao/winit about emacs-ng HOT 13 CLOSED

from emacs-ng.

I've still no real idea why it should happen; I thought the pselect/tokio loop was entirely inside rust-land?

We are using Rust ffi. Code is written in Rust doesn't help in this case. As for why it should happen, I have no clue either. I have no idea how the lisp interpreter works.

to be worth documenting I think.

I added some documentation here

from emacs-ng.

Hmm, I've just had helm fail with complaints about ^@. Has one sneaked in somewehere?

from emacs-ng.

And now we have a sigabrt inside wait_reading_process_output explictly caused by __stack_chk_fail. I think something is just stack smashing and the actual failure sites are random.

from emacs-ng.

from emacs-ng.

yeah, that was next on the list. But gdb can normally do a pretty good job of inferring the location even when not compiled with debug flags (at least in my limited experience). When the stack-smashing detection kicks in it's fine, but when the stack overflows and causes some random segfault it's (currently) lost.

from emacs-ng.

2e0byo @.***> writes:
And now we have a sigabrt inside wait_reading_process_output explictly caused by __stack_chk_fail. I think something is just stack smashing and the actual failure sites are random.
Can you try with --enable-winit-pselect? I have this random before using tokio async fd.

Definitely, that's a good shot.

I've got some more data on it: with tao the failure rate is 40% (out of 10 runs) and the first invocation of helm-M-x takes about a minute. (After that everything in helm is snappy). So if it's not the select loop it should just be a matter of profiling what on earth is taking so long. (helm-M-x in a terminal takes a second or so.) Something is pathological and occasionally killing the stack.

from emacs-ng.

Failure rates identical (40% and 50% out of 10 runs) between tao and winit.

Ofc winit passed the first 5 runs and tao failed the first 3 just to make me think it was significant :D

from emacs-ng.

This doesn't happen with --enable-winit-pselect. I think at the very least we should add a warning to the docs?

Although it didn't happen before the recent merges, i.e. in my dev branch.

from emacs-ng.

from emacs-ng.

Managed to profile a run with tokio:

Aside from why helm is even trying to load tramp just to get the M-x completions, I'm not much wiser---just blocking shouldn't kill the stack.

from emacs-ng.

2e0byo @.***> writes:
This doesn't happen with --enable-winit-pselect. I think at the very least we should add a warning to the docs?
My bad. If your branch is based of my old tao branch, this pselect code is used by default. See the conversation from here[0]. [0] #479

Drat. I saw that ofc at the time and did I quick check that everything behaved with tokio and then forgot about it.

This is sufficiently weird---I've still no real idea why it should happen; I thought the pselect/tokio loop was entirely inside rust-land? to be worth documenting I think. Anyhow thank you very much!

from emacs-ng.

great; was leaving this open till I got round to it so I'll close it.

from emacs-ng.