AppImage / type2-runtime

The runtime is the executable part of every AppImage. It mounts the payload via FUSE and executes the entrypoint.
Other
22 stars 17 forks source link

Something broke in the last 24 hours `terminate called after throwing an instance of 'appimage::update::AppImageError'` #69

Closed Samueru-sama closed 3 months ago

Samueru-sama commented 3 months ago

Hello, I recently made this PR and everything at the Brave appimage repo updating to use this appimagetool.

I've noticed that when trying to use appimageupdatetool it is throwing an error, that's odd since when I made the changes it was working perfectly.

Thankfully the CI was setup to make builds several times a day, so I can check where the error started

appimageupdatetool ./Brave-nightly-v1.70.76-x86_64.AppImage
terminate called after throwing an instance of 'appimage::update::AppImageError'
  what():  Unknown AppImage type or not an AppImage
zsh: IOT instruction  appimageupdatetool ./Brave-nightly-v1.70.76-x86_64.AppImage

The build log says that everything went fine

The issue is very likely upstream since appimagetool uses the CI zsync instead of bundling one, but I thought I would let you know anyway.

probonopd commented 3 months ago

Does appimagetool or appimage_update_tool have the issue?

Samueru-sama commented 3 months ago

Does appimagetool or appimage_update_tool have the issue?

The issue is when trying to use appimageupdatetool on newly made appimages. It doesn't happen with appimages made more than 24 hours ago.

I checked and the last appimageupdatetool build is from a month ago anyway.

Samueru-sama commented 3 months ago

The same v1.70.16 and newer builds made in the original repo of the Brave appimage don't have the issue.

image

The only difference between the two is the appimagetool, the original was using the appimagetool from AppImageKit while mine is using this appimagetool, and given that the issue started recently it is likely one of the utilities that are not bundled in this appimagetool, very likely zsyncmake

probonopd commented 3 months ago

Can you please compare the update information of the working and the non-working one by running both with --appimage-updateinformation?

Samueru-sama commented 3 months ago

Can you please compare the update information of the working and the non-working one by running both with --appimage-updateinformation?

image

gh-releases-zsync|AppImage|AppImageUpdate|continuous|appimageupdatetool-*x86_64.AppImage.zsync

It is the same info in both. the one with .new has the bug and the .old doesn't have the bug.

I just noticed that yesterday there was a new runtime build maybe it is something in the runtime?

EDIT: I just noticed that the info I posted makes no sense and you likely wanted the update info the appimages themselves, it is being added.

image

gh-releases-zsync|Samueru-sama|Brave-AppImage|nightly|Brave*.AppImage.zsync gh-releases-zsync|srevinsaju|Brave-AppImage|nightly|Brave*.AppImage.zsync

Samueru-sama commented 3 months ago

It is very likely something in the runtime.

I noticed that when I renamed the appimage to have the .new in the name, the icon in Thunar broke. It is no longer being recognized as an appimage.

Notice this, one build is from two days ago, and the other is recent, I added .test as the extension and the icon is broken in the recent build

image

In the end, the error appimageupdatetool was giving was what(): Unknown AppImage type or not an AppImage so it makes sense when even Thunar doesn't recognize it as an appimage anymore.

Samueru-sama commented 3 months ago

The issue is with the last build of the runtime, it makes the appimage no longer be recognize as an appimage by other programs like appimageupdatetool.

I tested it quickly with the Htop appimage that I have, I extracted it and made two appimages.

It fixed the issue, while neither htop appimage has update information, appimageupdatetool no longer errors out with what(): Unknown AppImage type or not an AppImage

image

Is it possible to transfer this issue to https://github.com/AppImage/type2-runtime ?

TheAssassin commented 3 months ago

The magic bytes are not there for some reason. Only an A is set, not AI\x02.

TheAssassin commented 3 months ago

To be fair, objcopy is probably right here to eliminate the magic bytes. They're somewhat offending the ELF spec. We've known that for years. We need to change their location.

Samueru-sama commented 3 months ago

Thanks for fixing it asap @TheAssassin