lorca
lorca copied to clipboard
zserge
lorca.New returns EOF because of lorca.readUntilMatch
Hi,
When trying to start Lorca-app with systemd, readUntilMatch from chrome.go returns EOF error. When started by user on command line, everything works.
Has anyone else come across this issue?
adding --no-sandbox args to lorca.New("", "", 480, 320, "--no-sandbox") will prevent EOF,
but windows will immediately close.
Just wanted to add I have 1 person seeing this as well on Windows but 15 others not seeing it with the same application. Seems to be persistent for that person. This is just a standard launch with Windows of the exe that launches Lorca with data.
I have also seen this in a deployed app on a windows system. Sadly, it is not my system and I do not have access to troubleshoot it.
Has anyone seeing this issue tried adding --enable-logging --v=1 to the command line arguments (under var defaultChromeArgs = []string{ in chrome.go)?
It would be good to see why chrome is crashing, that way, I think, to potentially get more info on why.
I got the info on chrome debug options/debug log file from: https://www.makeuseof.com/find-error-logs-to-troubleshoot-chrome/
Would very much appreciate if someone seeing this issue would try to turn chrome debug logs on and share the file output at (C:)/Users/[your username]/AppData/Local/Google/Chrome/User Data/chrome_debug, after triggering the issue, if possible.
Would also be good if someone seeing it on Linux could do the same, although I am currently mostly interested in Windows (since that is the platform my deployed app is triggering/seeing it).
Finally... Does anyone have any info to add to what is there at https://github.com/zserge/lorca/pull/121 ? Perhaps if I knew what was missing, there, I could work on filling the gaps...
Ok, one last thing: has anyone tried "retrying" the call to lorca.New, after detecting the EOF returned? Is that a possible workaround?
I would think it may work if --no-sandbox is added to launch arguments first (in chrome.go), since @BrightCandle mentioned the window closes immediately if you add that. Otherwise I think there would be a "blank" chrome window "hanging out", which may (or may not...) cause issues.
Sadly, I am unable to reproduce the issue and test it myself...
Has anyone seeing this issue tried adding
--enable-logging --v=1to the command line arguments (undervar defaultChromeArgs = []string{inchrome.go)?
It looks like for whatever reason, however lorca is interacting with spawning the Chrome proc, is causing this flag to not function correctly. The chrome_debug.log which appears in %AppData% normally, does not appear either there nor in the temp folder lorca creates when spawning chrome.
I'm experiencing the same as you stated - a few people using my app have noted this issue, but with varying builds and versions of Win 10, different browsers (Brave, Chrome, Vivaldi), and seemingly nothing to tie it together, or any way to replicate the issue.
On another note, I did attempt to apply the fixes noted in #121, to my own fork, however upon doing so, lorca errors out more spectacularly, and with a bit more of a usable error this time;
Get "http://127.0.0.1:59983/json/version/": dial tcp 127.0.0.1:59983: connectex: No connection could be made because the target machine actively refused it.
It might be worth looking into furthering the work done in #121 rather than trying to think about the --no-sandbox flag, as that seems a non-starter if it will immediately close the window (which appears to be baked in functionality of the flag).
I just saw @jujhar16's note:
And sometimes the browser has not started hosting the remote debugging version, which causes the json/version request to fail.
This seems like it might be solvable with a wait condition, though I'll defer to anyone else to do that, if they see fit. I'm reaching my wit's end with this issue.
My theory of using a "wait and retry" mechanism has worked.
It's not graceful at all, however it fixes the EOF error, and accounts for the TCP Dial error.
@DavidArthurCole I'm getting ready to try your fix. Should it be as simple as updating my fork of lorca with the commit you've linked ( https://github.com/DavidArthurCole/lorca/commit/2ed93e468a17486540e3f6f8df78865edfe89475 ) ?
@DavidArthurCole I'm getting ready to try your fix. Should it be as simple as updating my fork of lorca with the commit you've linked ( DavidArthurCole@2ed93e4 ) ?
I've made quite a many other updates to lorca previous to that fix, so I wouldn't recommend re-basing your HEAD to that commit. Better would be to "merge" the changes from #121 - i.e., rebase to this commit, and then update the logic around line 89 of chrome.go.
I do implore you to try to find a better solution than the retry though, haha - it's worked very well for my purposes, but it does leave the window "loading" a little bit longer, as even when successful, there's a still notable delay between lorca spawning, and the window populating. The retry mechanism will work, it's just not the prettiest.
@DavidArthurCole I noticed in your commit you updated x/net from 0.22 to 0.27. Is that a required update, or did you just update it because updating to latest is a best practice?
Just trying to figure that out because it may be tricky with my project setup to update that one, and seeing if I can avoid updating it without issues you might know of.
@DavidArthurCole I noticed in your commit you updated x/net from 0.22 to 0.27. Is that a required update, or did you just update it because updating to latest is a best practice?
Just trying to figure that out because it may be tricky with my project setup to update that one, and seeing if I can avoid updating it without issues you might know of.
Just did it out of best practice, unless it's throwing errors for you, wouldn't bother doing so if it's going to cause issues.
Would also be good if someone seeing it on Linux could do the same, although I am currently mostly interested in Windows (since that is the platform my deployed app is triggering/seeing it).
I've confirmed that this issue does in fact also occur on Linux machines.