Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

error in process sentinel: elfeed-curl--parse-write-out: Search failed: #248

Closed
alphapapa opened this Issue Nov 5, 2017 · 10 comments

Comments

Projects
None yet
2 participants
@alphapapa
Copy link

alphapapa commented Nov 5, 2017

Hi Chris,

I've been seeing this error sometimes, which seems to be accompanied with stuck processes (it still says "1 in process ...", and as I refresh more times in the future, sometimes the number of stuck processes increases):

error in process sentinel: elfeed-curl--parse-write-out: Search failed: "=d/0iSnFkRcu<KhO>vSL+="
error in process sentinel: Search failed: "=d/0iSnFkRcu<KhO>vSL+="

The string is different each time. Elfeed continues to work fine otherwise, but I don't know if certain feeds are getting stuck, or if it's random.

I'm using elfeed 20171103.737 with the curl backend.

Thanks for your help.

@alphapapa

This comment has been minimized.

Copy link
Author

alphapapa commented Nov 10, 2017

BTW, I've noticed that it seems to be a transient problem. e.g. if I use unjam and then refresh all the feeds again, they'll typically complete without error. Or I can even refresh without unjamming first, and usually they'll all complete without error, but leaving the originally stuck ones still stuck until I unjam.

Thanks.

@skeeto

This comment has been minimized.

Copy link
Owner

skeeto commented Nov 16, 2017

@alphapapa

This comment has been minimized.

Copy link
Author

alphapapa commented Nov 16, 2017

I'm on Linux, on Ubuntu 14.04, using Curl 7.35.0-1ubuntu2.12.

I don't think the <> are a problem. Here are two more of the boundary strings that I got from the messages buffer:

"=2q@MGiTvQcyha~cXg$>u="
"=scsf9z~~87NAZE|pPNN-="

Thanks.

@alphapapa

This comment has been minimized.

Copy link
Author

alphapapa commented Dec 6, 2017

Just a thought: I wonder if the problem is that the curl request failed, and rather than that being detected, the string is still searched for, which doesn't exist because the request failed.

@skeeto

This comment has been minimized.

Copy link
Owner

skeeto commented Dec 6, 2017

skeeto added a commit that referenced this issue Jan 17, 2018

Connect curl using a pipe rather than a pty (#248)
Emacs processes connected via PTY (the default) are plagued with issues
and have been for years:

* Control characters are interpreted by the PTY
* Mixing of stdout and stderr (eventually fixed)
* There's a nasty bug where output is truncated
* It's slow as hell
* It causes subprocesses to be line-buffered (also slow)

All the slowness and bugs can be fixed simply by switching to a pipe.
This is what Emacs' should have been using in the first place.
@skeeto

This comment has been minimized.

Copy link
Owner

skeeto commented Jan 17, 2018

@alphapapa

This comment has been minimized.

Copy link
Author

alphapapa commented Jan 17, 2018

Hi Chris,

That's great news! I'm really glad you were able to track it down. Thanks for digging into it.

For reference, I am on Ubuntu 14.04, but I'm using Emacs 25.2 that I built from newer source packages. It's the only version I've used Elfeed with so far. It does seem strange that it was so hard to reproduce, and that other users aren't reporting it. I wonder if it's an issue with underlying libraries.

Anyway, thanks for fixing this. Let me know if I can help further.

@alphapapa

This comment has been minimized.

Copy link
Author

alphapapa commented Jan 17, 2018

By the way, since this is a bigger issue that affects Emacs subprocesses, I wonder if if you should write a blog post about it... :)

@skeeto

This comment has been minimized.

Copy link
Owner

skeeto commented Jan 18, 2018

@alphapapa

This comment has been minimized.

Copy link
Author

alphapapa commented Jan 18, 2018

LOL, I should have known. :) Thanks.

@skeeto skeeto closed this May 8, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.