probonopd
commented
1 month ago Thanks for reporting. Never encountered this so far. Does it succeed on, e.g., Debian or Ubuntu?
Closed Simran-B closed 2 weeks ago
probonopd
commented
1 month ago Thanks for reporting. Never encountered this so far. Does it succeed on, e.g., Debian or Ubuntu?
Simran-B
commented
1 month ago I don't know as I haven't tried other OSes and I'm afraid I don't have the time to try it as it involves figuring out the names of dozens of packages and building various dependencies manually. I can upload the container where it failed though, if it helps?
chipolux
commented
1 month ago Same behavior on arch, I'm unfamiliar with the codebase but I was able to make a minor change to fix my case.
There appear to be two bugs, one is that e.Close() is not called before the loop that recurses back into getDeps(), which can exhaust file descriptors if there are very deeply nested dependency trees. This is what actually happened on my system rather than a stack overflow.
The second bug, which seems like there might be handling for that I didn't grok, is the simple circular recursion loop of getDeps() getting called within itself, for itself, forever. My quick and dirty patch kinda mirrors stuff that already exists with allELFs, etc.
If it helps, I added log.Println(">> getDeps()", binaryOrLib) to the top of getDeps() and got this loop until it exhausted file descriptors, then I added the e.Close() and it in this same loop for much longer, over 30 minutes, so I killed it but I imagine it would eventually crash. Finally with the addition of collecting and checking seenDeps it finished in maybe 1 second. And the built AppImage is working fine so far.
2024/05/31 17:57:45 >> getDeps() /usr/lib64/ld-linux-x86-64.so.2
2024/05/31 17:57:45 >> getDeps() /usr/lib64/libfreetype.so.6
2024/05/31 17:57:45 >> getDeps() /usr/lib64/libz.so.1
2024/05/31 17:57:45 >> getDeps() /usr/lib64/libc.so.6
2024/05/31 17:57:45 >> getDeps() /usr/lib64/ld-linux-x86-64.so.2
2024/05/31 17:57:45 >> getDeps() /usr/lib64/libharfbuzz.so.0
2024/05/31 17:57:45 >> getDeps() /usr/lib64/libm.so.6
2024/05/31 17:57:45 >> getDeps() /usr/lib64/libc.so.6
2024/05/31 17:57:45 >> getDeps() /usr/lib64/ld-linux-x86-64.so.2diff --git a/src/appimagetool/appdirtool.go b/src/appimagetool/appdirtool.go
index 77bb58e..bc666e6 100644
--- a/src/appimagetool/appdirtool.go
+++ b/src/appimagetool/appdirtool.go
@@ -34,6 +34,7 @@ type QMLImport struct {
var allELFs []string
var libraryLocations []string // All directories in the host system that may contain libraries
+var seenDeps []string
var quirksModePatchQtPrfxPath = false
@@ -974,6 +975,10 @@ func findAllExecutablesAndLibraries(path string) ([]string, error) {
}
func getDeps(binaryOrLib string) error {
+ if containsString(seenDeps, binaryOrLib) == true {
+ log.Println("skipping already seen dep, circular ref", binaryOrLib)
+ return nil
+ }
var libs []string
if helpers.IsDirectory(binaryOrLib) == true {
@@ -994,6 +999,10 @@ func getDeps(binaryOrLib string) error {
libs, err = e.ImportedLibraries()
helpers.PrintError("e.ImportedLibraries", err)
+ err = e.Close()
+ helpers.PrintError("e.Close", err)
+
+ seenDeps = helpers.AppendIfMissing(seenDeps, binaryOrLib)
for _, lib := range libs {
s, err := findLibrary(lib)
if err != nil {Thanks @chipolux. Could you send a pull request please?
chipolux
commented
3 weeks ago Oops, sorry for the delay, got busy, but sure thing!
Simran-B
commented
3 weeks ago With the patch, appimagetool finishes pretty quickly for me, printing "skipping already seen dep, circular ref" 517 times. Thanks!
Unfortunately, turning the AppDir into an AppImage still fails - appstreamcli segfaults with exit code 139 when it validates the appdata.xml but I see nothing wrong in there 😞
probonopd
commented
3 weeks ago Just delete the appdata.xml to see if it continues then...
Simran-B
commented
3 weeks ago appstreamcli seems to crash for all kinds of reasons, if mandatory elements are missing or if it doesn't know certain constructs it seems. The segfaults seem to be fixed in newer versions (I checked with 1.0.3) and the error reporting is pretty good. The version that comes with appimagetool (?) seems to be from 2019 (v0.12.9).
I managed to fix the appdata.xml file, at least when using the extracted appstreamcli executable from a temp folder (/tmp/appimage_extracted_e56b...930d/usr/bin/appstreamcli). For some reason, using appimagetool, appstreamcli still segfaults unless I delete the appdata.xml 🤷
probonopd
commented
2 weeks ago Closing here, since "Stack overflow gathering libs" appears to be fixed. Thanks @chipolux. For other issues, please open new tickets (in case they don't exist yet).
appimagetool version 185
I tried to create an AppImage from a Qt 5 application built under Arch (latest Docker image) but it failed after running for almost an hour:
I normally use linuxdeployqt but it requires
-unsupported-allow-new-glibcand terminates without creating an AppImage but also not logging any errors.