Closed JuPlutonic closed 3 years ago
But, when I run it run like ./AppImageUpdater-v2.0.0-x86_64.AppImage FreeTube_0.12.0_amd64_3d718a51d0088ee3984b5bc5b1933b33.AppImage
(any .appimage file), it opens it like this:
QApplication: invalid style override passed, ignoring it.
Available styles: Windows, Fusion
OS: elementary OS 5.1.7 Hera (5.1.7)
CPU Architecture: x86_64
Kernel Version: 5.4.0-72-generic
QAppImageUpdate Version: 2.0.2
LibTorrent Rasterbar Version: 1.2.8.0
AppImage Updater Commit: a8a4169
AppImage Updater Build Number: 77
W/o seqmentation error and w/o updating—processing of the file from the argument (FreeTube_0.12.0_amd64_3d718a51d0088ee3984b5bc5b1933b33.appimage).
-d --standalone-update-dialog
works.
If the standalone update dialog works then it means that it's a QML error. I will look into it. Thanks for reporting.
@JuPlutonic I don't quite understand it.
I just ran v2.0.0 in elementary OS 5.1.7 Hera and there is only some error messages but the application seems to work fine. Also regarding passing arguments to the main applicatoin. There is no option for this due to design reasons and that's why we have standalone dialogs. Can you clearly explain what's your issue? is it segmentation fault?? Some ways I can reproduce?
The main application you need to drag and drop desktop file, AppImage or directory with collection of AppImages. Or browse if you want but you can't pass a AppImage directly from the command line but you can use -d argument for that.
I restarted terminal and loose ends.
Only segmentation faul remainingif I dragging zsync-contained file then I alternate it with next file balenaEther (w/o zsync info), and, finally drugging again zsync-contained file.
INFO: setAppImage : "/opt/Applications/appimage-cli-tool-0.1.4-x86_64.AppImage" . INFO: getInfo : AppImage is confirmed to be type 2. INFO: getInfo : mapping AppImage to memory. INFO: getInfo : AppImage architecture is x86_64 (64 bits). INFO: getInfo : updateString( "gh-releases-zsync|AppImageCrafters|appimage-cli-tool|latest|appimage-cli-tool-*x86_64.AppImage.zsync" ). INFO: getInfo : finished. INFO: setControlFileUrl : using github releases zsync transport. INFO: setControlFileUrl : github api request( QUrl("https://api.github.com/repos/AppImageCrafters/appimage-cli-tool/releases/latest") ). FATAL: handleNetworkError : QNetworkReply::SslHandshakeFailedError . INFO: handleGithubAPIResponse : starting to parse github api response. Failed:: 1 INFO: setAppImage : "/opt/Applications/balenaEtcher-1.5.109-x64.AppImage" . INFO: getInfo : AppImage is confirmed to be type 2. INFO: getInfo : mapping AppImage to memory. INFO: getInfo : AppImage architecture is x86_64 (64 bits). FATAL: getInfo : update information is empty. Failed:: 2 INFO: setAppImage : "/opt/Applications/DB_Browser_for_SQLite--x86_64.AppImage" . INFO: getInfo : AppImage is confirmed to be type 2. INFO: getInfo : mapping AppImage to memory. INFO: getInfo : AppImage architecture is x86_64 (64 bits). INFO: getInfo : updateString( "gh-releases-zsync|sqlitebrowser|sqlitebrowser|continuous|DB_Browser_for_SQLite*-x86_64.AppImage.zsync" ). INFO: getInfo : finished. INFO: setControlFileUrl : using github releases zsync transport. INFO: setControlFileUrl : github api request( QUrl("https://api.github.com/repos/sqlitebrowser/sqlitebrowser/releases/tags/continuous") ). free(): double free detected in tcache 2 FATAL: handleNetworkError : QNetworkReply::SslHandshakeFailedError . INFO: handleGithubAPIResponse : starting to parse github api response. zsh: abort (core dumped) ./AppImageUpdater-v2.0.0-x86_64.AppImage
So first you dragged a AppImage with zsync update , then balenaEtcher which does not have zsync info and finally a AppImage with zsync info then it crashed like this.
The interesting part is,
FATAL: handleNetworkError : QNetworkReply::SslHandshakeFailedError
free(): double free in tcache2
I will look into this ASAP.
Yes, ok, I dumped crush https://gofile.io/d/atK9xE, it's actually 266Mb bzipped to 15M.
Yep, something happend to cache/tmp during zsync download.
@JuPlutonic This seems like a network problem of some sort. Are you using a proxy or some kind of special network or something. Thanks for the debug information but I really can't debug the dump since AppImages are not debugger friendly(I tried to). The application output in the terminal gives us more information.
Now I want to know when does this error occur, can you reproduce it everytime or randomly?? Because in my Virtual Installation I have no SSL errors or segmentation fault. I even tried to reproduce your case. I can't reproduce your case at all.
To reproduce i need 2 times drop / select appimages (with zsync).
Selecting different types of connection WAN/Cellular/torified-shell didn't make difference.
Update I overcome termination/crush when run LD_LIBRARY_PATH="/home/user/squashfs-root/usr/lib" ~/squashfs-root/AppRun -style=Fusion
command (--appimage-expract (-ed)), also I deleted /home/user/.drirc file.
Now I can work with /opt/AppImageUpdater-v2.0.0-x86_64.AppImage
without crushing. Thank you for help!
Hmm... Nice to see it's fixed. But you should always execute the AppImage without extracting. LD_LIBRARY_PATH will be automatically set if you execute the AppImage not the AppRun directly.
Last version 2.0.0 has seqmentation fault, 2.0.0beta1 hasn't got faults except the need to launch it with
export QT_STYLE_OVERRIDE=Fusion
OR-style=Fusion
.Linux userpc 5.4.0-72-generic #80~18.04.1-Ubuntu SMP Mon Apr 12 XXX 2021 x86_64 x86_64 x86_64 GNU/Linux OS: elementaryOS 5.12.9 Hera(Ubuntu 18.04 w/o any Qt installed) echo $QT_QPA_PLATFORMTHEME ``— empty, /home/user/.AppImageUpdater.lock and /home/user/core files — deleted.