v1.8.0 crashes on launch (Windows)

[sfkpmr]

Bug report

• I understand the difference between Streamlink and Streamlink Twitch GUI.
• This is a bug report and I have read the contribution guidelines.

Environment details

Operating system and version:
Windows 7 x64

Streamlink Twitch GUI version:

Streamlink version:
1.1.0

Description

Expected / Actual behavior

Twitch GUI immediately closes down after starting on v1.8.0. Previously used v1.7.1 without problem. Uninstalled and installed again with same issue. Installed v1.7.1 which immediately works.

[Conjuro]

Same issue. Same OS, Streamlink version 1.1.1.

GUI loads, activity indicator spins, proxy shows network requests are made to Twitch servers, then process closes completely.

Will provide logs shortly.

[bastimeyer]

I can't reproduce this in my win7 VM. The built win64 archive and installer are working fine here. I've also tested a locally built release on a native win10 install.

This is very likely related to the NW.js bump to 0.40.0. There is a 0.40.1 release, but the changelog doesn't say anything about win7 issues.
https://github.com/nwjs/nw.js/blob/nw40/CHANGELOG.md

Please clear your user-data-dir and provide a proper log output if it keeps crashing.

[Conjuro]

Clearing user-data-dir works, though 'Featured' homepage is just showing the spinner, can change to 'Games' and 'Streams' and successfully start a stream.

Following is from before I cleared user-data-dir:

Ran with loglevel Debug.

%TMP%\streamlink-twitch-gui\logs\2019-08-08_20-44-36.log:

Parameters
{
    "_": [],
    "tray": false,
    "hide": false,
    "hidden": false,
    "max": false,
    "maximize": false,
    "maximized": false,
    "min": false,
    "minimize": false,
    "minimized": false,
    "reset-window": false,
    "versioncheck": true,
    "version-check": true,
    "logfile": true,
    "loglevel": "debug",
    "l": "debug",
    "launch": "",
    "goto": ""
}

C:\ProgramData\Chocolatey\lib\streamlink-twitch-gui\streamlink-twitch-gui\debug.log:

[0808/204437.431:WARNING:process_subrange_reader.cc(60)] range 0x1401ce000 + 0x5a8c8 (64) outside of  range 0x140000000 + 0x1ec000 (64) for C:\ProgramData\chocolatey\lib\streamlink-twitch-gui\streamlink-twitch-gui\streamlink-twitch-gui.exe resources
[0808/204437.477:ERROR:http_transport_win.cc(178)] WinHttpCrackUrl: The operation completed successfully. (0x0)

Any other logs I can provide?

[bastimeyer]

'Featured' homepage is just showing the spinner

Yeah, there seems to be an issue with Twitch right now, but that's nothing which would cause the app to crash.
In case anyone is wondering if it's related to the v3 API shutdown on 2019-08-12, no, featured streams are still part of the v5 API:
https://dev.twitch.tv/docs/v5/reference/streams/#get-featured-streams

Other API endpoints are also loading very slowly right now.

Any other logs I can provide?

The default log verbosity level of Chromium is set to "error", so I don't think there's anything you can do other than posting Chromium's crash log.

---

Looks like there was a shutdown crash during the build, too, during the test and code coverage run:
https://travis-ci.org/streamlink/streamlink-twitch-gui/builds/569469953#L806-L821

Looks like there's definitely an issue with NW.js 0.40.0.

Unfortunately, I can't roll-back the used NW.js version, because it's not supported. People will get an error message when attempting to use a newer user-data-dir.

This needs to be reported to NW.js once the issue has been found.

[bastimeyer]

I'll add a note to the releases page for now that people should clear their user-data-dir if the app keeps crashing.

There's unfortunately nothing else which I can do. Maybe I could bump it to 0.40.1 and release 1.8.1, but I doubt that this will help. If one wants to test 0.40.1 on their own though, they are very welcome to do so.
https://github.com/streamlink/streamlink-twitch-gui/blob/v1.8.0/src/config/main.json#L4
https://github.com/streamlink/streamlink-twitch-gui/blob/v1.8.0/CONTRIBUTING.md#developing-and-building

[fearlesschicken]

Cleared %localappdata% and I was able to start the app again. As soon as I try to login with an access token or oauth, it crashes and doesn't save.

OS: Win 10 x64
Updated from 1.7.1

[richarjw1]

Same Issue:
OS: Win 10 1903 x64
Updated from 1.7.1
Strealink 1.1.1.

[infiniteflow24]

Same issue.
OS: Win 10 1903 / 18362.267/ x64
Updated from 1.7.1
Strealink 1.1.1.

bastimeyer said : "I'll add a note to the releases page for now that people should clear their user-data-dir if the app keeps crashing."

So I deleted C:\Users\username\AppData\Local\streamlink-twitch-gui
And then streamlink-twitch-gui was worked.
But when i tried to login with my twitch account. it was shut down Immediately.

[MrLint]

I also tried the advanced login by entering the access token and as soon as it push the button to use it it crashed.

[MrLint]

I did some very ad-hoc testing and 1.8.0 works fine if you replace all the files with the nw.js package v0.39.3 and does NOT work with v0.40.1

[bastimeyer]

I went to bed for a couple of hours. Trying to debug this now.

Yep, NW.js crashes on login on Win7. Probably related to the teardown of the local webserver once the login in completes or related to writing to the LocalStorage.

./streamlink-twitch-gui.exe
[3208:3872:0808/174827.318:ERROR:google_update_settings.cc(248)] Failed opening key Software\nwjs to set usagestats; result: 5
[3208:3768:0808/174827.349:ERROR:component_loader.cc(168)] Failed to parse extension manifest.
[3208:3768:0808/174849.270:FATAL:ref_counted.cc(66)] Check failed: --ref_count_ != std::numeric_limits<decltype(ref_count_)>::max().
Backtrace:
        v8::internal::TorqueGeneratedExportedMacrosAssembler::StoreSortStateNumberOfUndefined [0x000007FED8DA4112+7918114]
        v8::internal::TorqueGeneratedExportedMacrosAssembler::StoreSortStateNumberOfUndefined [0x000007FED8DA3772+7915650]
        v8::internal::TorqueGeneratedExportedMacrosAssembler::StoreSortStateNumberOfUndefined [0x000007FED8DBC419+8017193]
        v8::internal::TorqueGeneratedExportedMacrosAssembler::StoreSortStateNumberOfUndefined [0x000007FED8DC0FC8+8036568]
        RelaunchChromeBrowserWithNewCommandLineIfNeeded [0x000007FEDC2CE030+30547184]
        v8::CpuProfileNode::GetParent [0x000007FED7811EF7+1007479]
        v8::CpuProfileNode::GetParent [0x000007FED781358B+1013259]
        v8::CpuProfileNode::GetParent [0x000007FED7813929+1014185]
        v8::CpuProfileNode::GetParent [0x000007FED78302AB+1131307]
        v8::CpuProfileNode::GetParent [0x000007FED783019C+1131036]
        GetHandleVerifier [0x000007FED9F2ED7D+6621293]
        v8::internal::Space::ResumeAllocationObservers [0x000007FED7685DF4+185732]
        v8::internal::compiler::MachineOperatorBuilder::Word64And [0x000007FED742C26C+73132]
        v8::CpuProfile::GetSamplesCount [0x000007FED75B4551+105313]
        v8::internal::TorqueGeneratedExportedMacrosAssembler::StoreSortStateNumberOfUndefined [0x000007FED903C2E8+10638328]
        v8::internal::TorqueGeneratedExportedMacrosAssembler::StoreSortStateNumberOfUndefined [0x000007FED8DFA9E1+8272625]
        IsSandboxedProcess [0x000007FED98D4126+6457970]
        IsSandboxedProcess [0x000007FED98D3E21+6457197]
        v8::internal::TorqueGeneratedExportedMacrosAssembler::StoreSortStateNumberOfUndefined [0x000007FED8DC3C14+8047908]
        v8::internal::TorqueGeneratedExportedMacrosAssembler::StoreSortStateNumberOfUndefined [0x000007FED8DC34BE+8046030]
        IsSandboxedProcess [0x000007FED98D4956+6460066]
        v8::internal::TorqueGeneratedExportedMacrosAssembler::StoreSortStateNumberOfUndefined [0x000007FED8DE28AE+8174014]
        RelaunchChromeBrowserWithNewCommandLineIfNeeded [0x000007FEDA5AED09+10697]
        v8::internal::LookupIterator::GetAccessorIndex [0x000007FED7304EF5+264517]
        v8::internal::LookupIterator::GetAccessorIndex [0x000007FED7306D13+272227]
        v8::internal::LookupIterator::GetAccessorIndex [0x000007FED730226D+253117]
        v8::internal::TorqueGeneratedExportedMacrosAssembler::StoreSortStateNumberOfUndefined [0x000007FED8D4056E+7509630]
        v8::internal::TorqueGeneratedExportedMacrosAssembler::StoreSortStateNumberOfUndefined [0x000007FED8D410CC+7512540]
        v8::internal::TorqueGeneratedExportedMacrosAssembler::StoreSortStateNumberOfUndefined [0x000007FED8D40D6C+7511676]
        v8::internal::TorqueGeneratedExportedMacrosAssembler::StoreSortStateNumberOfUndefined [0x000007FED8D4A93F+7551567]
        v8::internal::TorqueGeneratedExportedMacrosAssembler::StoreSortStateNumberOfUndefined [0x000007FED8D404DE+7509486]
        ChromeMain [0x000007FED68011B0+280]
        (No symbol) [0x0000000140002FAB]
        (No symbol) [0x00000001400015CD]
        (No symbol) [0x0000000140135A02]
        BaseThreadInitThunk [0x00000000771C652D+13]
        RtlUserThreadStart [0x00000000773FC521+33]
Task trace:
Backtrace:
        v8::internal::TorqueGeneratedExportedMacrosAssembler::StoreSortStateNumberOfUndefined [0x000007FED903C298+10638248]
        v8::internal::TorqueGeneratedExportedMacrosAssembler::StoreSortStateNumberOfUndefined [0x000007FED8E8CF20+8871984]
IPC message handler context: 0x8DDC323E

[0808/174849.777:ERROR:http_transport_win.cc(178)] WinHttpCrackUrl: The operation completed successfully. (0x0)

Not sure what to do with the release now. It would make sense moving 1.8.0 to a pre-release so that people don't get update notifications. A rollback of NW.js is unfortunately not possible. Once I find the real culprit and am able to reliably reproduce it, I will submit this issue to the NW.js devs.

[bastimeyer]

Looks like 0.40.1 is crashing as well, 0.39.3 however is not. I'm going to submit a bug report with crashdumps to NW.js.

The crash is not directly related to the login. I was able to walk through the code step by step in a dev build and it crashed during the transition to one of the user-routes after the login, and I'm not sure why.

---

I'll probably have to roll-back to 0.39.3 now and accept that there will be users with a (one-time) downgrade error popup (unless they clear their user-data-dir). 1.8.0 is only a couple of hours old, so it's probably the best to do it now. I will also have to revert the theme detection changes, as it's only supported on 0.40.0 (Chromium 76).

[bastimeyer]

Just released v1.8.1 with a downgrade of NW.js to 0.39.3.
https://github.com/streamlink/streamlink-twitch-gui/releases/tag/v1.8.1

See the current build status here (will take ~20mins to complete):
https://travis-ci.org/streamlink/streamlink-twitch-gui/builds/569640177

As noted in the changelog, people who have already upgraded to v1.8.0, regardless the OS, will receive a downgrade error message in the future (unless they want to delete their user-data-dir):
https://github.com/streamlink/streamlink-twitch-gui/blob/v1.8.1/CHANGELOG.md#v181-2019-08-09

[bastimeyer]

New release here:
https://github.com/streamlink/streamlink-twitch-gui/releases/latest

Thanks for the reports, everyone!

[sfkpmr]

@bastimeyer Thanks for the fix and all the work!

[bastimeyer]

Let's keep this thread up for a bit until everyone affected by the bad release had a chance to see it.

[MrLint]

@bastimeyer I apologize if this is inappropriate on this bug, however as above I did some ad-hoc testing and replaced the nw files with the 39.3, however the info in 1.8.0 still shows 40.0. This of course seems totally normal that you'd have the version number hard coded into the app when you build it. Its perfectly reasonable to not expect someone to slice and dice the parts together. But for troubleshooting purposes should it read the actual version for the info window?

[bastimeyer]

You can't simply replace the files. The built and minimized app code gets appended to the executable file by nw-builder in a production build. If you replace the executable with a different one, then you will lose the app content, and if you only replace the other files, then you will have library mismatches when trying to run it.

There are other ways of distributing NW.js app builds, but AFAIK, nw-builder doesn't support this (or its support is limited). I would like to change that though, as appending the app content to the executable is not ideal. But since we're also replacing the embedded icon on Windows, it's not really important.

If you want to experiment with other NW.js versions, just use the intended build steps which I've linked above. Even on Windows it's very simple.

however the info in 1.8.0 still shows 40.0

Do you mean the about page? That uses a hardcoded JSON object which gets generated during the build and is included in the app code.

But for troubleshooting purposes should it read the actual version for the info window?

I could add a message if the versions don't match, but it's very unlikely for the app to be run by a NW.js runtime which it wasn't built for.