Deltachat-desktop: syntax error: r1.1.0 crashes at startup

[missytake]

• Platform (linux/mac/windows): linux
• Delta Chat Desktop Version: r1.1.0
• Expected behavior: starts as usual, shows a window
• Actual behavior: crashes with uncaught SyntaxError exception at JSON.parse
• Steps to reproduce the problem:
  
  
  
  • stop the desktop client
  
  
  • install r1.1.0
  
  
  • start it in a terminal to get this traceback:
  
  

A JavaScript error occurred in the main process
Uncaught Exception:
SyntaxError: Unexpected token u in JSON at position 0
    at JSON.parse (<anonymous>)
    at Object.setLogHandler (/opt/DeltaChat/resources/app.asar/tsc-dist/shared/logger.js:35:15)
    at Object.<anonymous> (/opt/DeltaChat/resources/app.asar/tsc-dist/main/index.js:21:8)
    at Module._compile (internal/modules/cjs/loader.js:786:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:798:10)
    at Module.load (internal/modules/cjs/loader.js:645:32)
    at Function.Module._load (internal/modules/cjs/loader.js:560:12)
    at Module.require (internal/modules/cjs/loader.js:685:19)
    at require (internal/modules/cjs/helpers.js:16:16)
    at Object.<anonymous> (/opt/DeltaChat/resources/app.asar/index.js:5:1)

• Logs:

the logfile is empty.

[r10s]

same on mac:

[francwalter]

Same on Windows 8.1 (Ent. 64-Bit) with already DeltaChat 1.0 installed.
After install of this DeltaChat v1.1 the above crash comes up:

I reverted to 1.0 (installed 1.0 again over it) and Delta Chat works again.

[missytake]

exit code 0 btw... would expect it to be 1 for an error.

[r10s]

similar reports in the forum https://support.delta.chat/t/deltachat-desktop-1-1-0-linux-did-not-start/880

[Simon-Laux]

strange, I did not get that on a local build, maybe the build script didn't work properly and packed old files.

[Jikstra]

Not reproducible on arch. @Simon-Laux please test releases on various platforms before uploading them.

[pabzm]

On my Arch Linux https://download.delta.chat/desktop/r1.1.0/DeltaChat-1.1.0.AppImage does fail with the described error.

[Jikstra]

So it seems like all electron builder builds fail. The AUR package isn't using electron builder and might work fine because of that.

[gerryfrancis]

Same behavior on Windows 8.1 Pro.

[Simon-Laux]

Thanks for your information. The bug was not in the release, but in the build script that actually used some files from the previous build because it was broken. I now fixed it and already it replaced the uploaded files. Please re-download and test again.

[gerryfrancis]

@Simon-Laux It works now, many thanks for the fast fix! :+1:

[r10s]

yip, i can also confirm that this works on mac now.

@Simon-Laux was there a pr or so to fix that? or was it just a think going wrong on your local machine? for the future, however, i would prefer to have new version number and a new file in any case. having two file names with different versions tend to cause confusion (eg. downloads may be cached etc.)

another thing: the about dialog reports using core v1.26.0 - so the versions seems not to fix the encrypt-to-ecc-issue, i will file a separate issue for that. in fact, core1.26 does fix the encrypt-to-ecc-issue but has some problems on some platforms, maybe it is okay to use that for desktop for now, not sure. if in doubt, i would use 1.27 :)

[Simon-Laux]

@Simon-Laux was there a pr or so to fix that? or was it just a think going wrong on your local machine? for the future, however, i would prefer to have new version number and a new file in any case. having two file names with different versions tend to cause confusion (eg. downloads may be cached etc.)

as I said the build was broken, it didn't build the actual version. so there was no change to the source-code as the error was in the local build script. I should have marked it as pre-release or draft in github, though.

[r10s]

I should have marked it as pre-release or draft in github, though.

at least on android or ios, we usually do not to that on the release track.

we usually release versions as _1.2.0_ and push them to the testing groups. we do not mark them as pre-release or so in the version number.

• if things work out, this _exact, binary identical_ apk/ipc is pushed to the stores - changing the version number would require a rebuild and has some risk - as happens in this issue.

• if things go wrong, we do a _1.2.1_ and start over.

for releases that are not supposed to make it to the release track, of course, this is a different thing.

EDIT: and of course, if it is a tag on github, as you are talking about, this can be changed more easily and less risky :)

anyway - thanks for the quick fix :)