Package: liblasi0 Version: 1.1.0-2 Severity: important Dear Maintainer,
Since one of my recent Debian Buster upgrades I have been getting the following run-time errors with libLASi when a missing system glyph is encountered: terminate called after throwing an instance of 'std::runtime_error' what(): Error returned from FT_Load_Glyph Aborted You definitely don't want libLASi to throw errors and abort when encountering missing system glyphs because that situation is fairly common. Therefore, I have rated the severity level of this bug as important. The relevant libLASi code that attempts to do something responsible when encountering missing system glyphs is the following code in libLASi-1.1.0 (and also libLASi-1.1.2). FT_Error error = FT_Load_Glyph(face,glyph_index,FT_LOAD_NO_BITMAP); if(error){ // //DEBUG: // //std::cerr << "PANGO is returning a glyph index of " << std::hex << glyph_index << std::endl; //std::cerr << "but PANGO_GLYPH_UNKNOWN_FLAG is supposed to be: " << 0x10000000 << std::endl; //std::cerr << "and PANGO_GLYPH_EMPTY is supposed to be: " << 0x0FFFFFFF << std::endl; // // Substitute something that works: All fonts are supposed // to handle glyph_index 0 as the default replacement glyph: // evalReturnCode(FT_Load_Glyph(face,0,FT_LOAD_NO_BITMAP),"FT_Load_Glyph"); }else{ evalReturnCode(FT_Load_Glyph(face, glyph_index,FT_LOAD_NO_BITMAP), "FT_Load_Glyph"); } where evalReturnCode is the following inline routine (in both 1.1.0 and 1.1.2): /** Converts a freetype return code into an exception. */ inline void evalReturnCode(const int errCode, const char* funcName) throw (std::runtime_error) { if (errCode) throw std::runtime_error(std::string("Error returned from ") + funcName); } So the obvious purpose of the above code is whenever there is some issue with FT_Load_Glyph for a give glyph_index it tries again with glyph_index = 0 which according to the above notes should always "just work" without throwing an error. In any case this technique for avoiding throwing errors on missing glyphs worked perfectly over the years, and I can see no reason why it has suddenly started throwing errors now. But since my recent Debian Buster upgrades did not involve libLASi, this bug should likely be reported against one of the many dependencies of libLASi, but I don't know which one so I have started the process by reporting the bug here. I haven't tried this myself yet, but I am virtually positive you can easily verify this issue by building and running libLASi-1.1.0/examples/MissingGlyphExample.cpp. Instead of performing that direct test of libLASi, I have been indirectly testing libLASi over many years via regular PLplot testing since PLplot includes the psttf device which links to libLASi. The examples we test do include missing glyphs, and my recent PLplot tests have recently started erroring out with the above abort for our psttf device driver which is the motivation for this bug report. FYI, I am far from expert with libLASi and C++, but I do have some familiarity with the libLASi code because I have helped some upstream with its build system and bug releases over the years (because of my PLplot interest). So if there are some further tests you would like me to try because you are having trouble verifying this bug with MissingGlyphExample.cpp, please let me know. Alan -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.18.10-custom (SMP w/16 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages liblasi0 depends on: ii libc6 2.28-2 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3 ii libgcc1 1:8.2.0-13 ii libglib2.0-0 2.58.2-3 ii libpango-1.0-0 1.42.4-6 ii libpangoft2-1.0-0 1.42.4-6 ii libstdc++6 8.2.0-13 liblasi0 recommends no packages. liblasi0 suggests no packages. -- no debconf information