Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-84272

Endless loop due to encoding problem in library path

    XMLWordPrintable

Details

    • Linux/X11, macOS
    • 19b6ae6637bde73ec508b6d1d29f3233e2c4e2d4 (qt/qtbase/dev) 973f0cee9e8134f2a647281aa36bc28d9255a1ee (qt/qtbase/5.15)

    Description

      When deploying a dynamically-linked application, the application might hang at startup, not showing any window but not quitting either.

       

      After some investigation, I was able to identify that this happens when there are some non-ASCII characters in the path leading to the library (I deployed the application with a startup script that set LD_LIBRARY_PATH to point to the Qt libraries I provided).

      Running the application in a debugger shows that there is an endless loop in the qlibraryinfo.cpp file, in the getRelocatablePrefix() function. Printing the path shows that there is an encoding problem : the path is an UTF-8 string that has been interpreted as a latin1 string (which can also be seen using strace).

      Investigating the function, I found the four following lines in qlibraryinfo.cpp (lines 574 to 577 in my version, 5.14.2) :

      Dl_info info;
       int result = dladdr(reinterpret_cast<void *>(&QLibraryInfo::isDebugBuild), &info);
       if (result > 0 && info.dli_fname)
       prefixPath = prefixFromQtCoreLibraryHelper(QString::fromLatin1(info.dli_fname));

      What actually happens is that dladdr() fills the info struct with path encoded in UTF-8 (my console encoding), but then the prefixPath variable is set decoding it with QString::fromLatin1(), thus leading to an incorrect encoding.

      I am not sure whether the behaviour of dladdr() is well-defined concerning the encoding of the strings, but on my system (Fedora 31), it uses the console encoding. I can confirm that by changing my console encoding (through the LANG variable) to iso88591, and running the app without any problem. If this behaviour is documented, I may suggest changing the QString::fromLatin1 to some system-dependent alternative (fromLocal8Bit() ?). I did not ask for a pull-request, because I am not sure this would fit any system.

      I am aware that putting non-ASCII characters in path is a bad habit, and I personnaly never do that, but since some major Linux distributions come with default path names containing some of these (e.g. "Downloads" becomes "Téléchargements" in French, hence launching the app from a subfolder of this directory triggers this behaviour), I think it is worth opening an issue.

      If you do not plan to fix this, it may be interesting to, at least, mention this on the documentation page about deploying applications (https://doc.qt.io/qt-5/linux-deployment.html).

      Best regards,
      MR

      Attachments

        Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            People

              alexandru.croitor Alexandru Croitor
              mr Matthieu Renard
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Gerrit Reviews

                  There are no open Gerrit changes