Re: AOO 4.1.16-RC3 libexpat-related crash on openSUSE
Hello All, On Sat, Oct 11, 2025 at 07:31:53PM +0200, Matthias Seidel wrote: > Hi Arrigo, > > Am 11.10.25 um 15:15 schrieb Arrigo Marchiori: > > Dear All, > > > > I am seeing AOO 4.1.16-RC3 crash on openSUSE due to an issue with libexpat. > > > > Stack trace (I have debug symbols installed for fontconfig): > > #0 0x in ??? () > > #1 0x764fddde in ??? () at /usr/lib64/libexpat.so.1 > > #2 0x765022fc in XML_ParseBuffer () at /usr/lib64/libexpat.so.1 > > #3 0x76c562e4 in FcConfigParseAndLoadFromMemoryInternal > > (config=config@entry=0x712eb0, filename=filename@entry=0x7130f0 > > "/etc/fonts/fonts.conf", buffer=, complain=complain@entry=1, > > load=load@entry=1) at fcxml.c:3547 > > #4 0x76c56941 in _FcConfigParse > > (config=config@entry=0x712eb0, name=name@entry=0x0, > > complain=complain@entry=1, load=load@entry=1) at fcxml.c:3682 > > #5 0x76c591da in IA__FcConfigParseAndLoad > > (config=config@entry=0x712eb0, name=name@entry=0x0, > > complain=complain@entry=1) at fcxml.c:3719 > > #6 0x76c472a8 in FcInitLoadOwnConfig (config=0x712eb0, > > config@entry=0x0) at fcinit.c:89 > > #7 0x76c47506 in FcInitLoadOwnConfigAndFonts > > (config=config@entry=0x0) > > at fcinit.c:170 > > #8 0x76c47534 in IA__FcInitLoadConfigAndFonts () at fcinit.c:184 > > #9 0x76c38916 in FcConfigEnsure () at fccfg.c:96 > > #10 0x76c38979 in FcConfigInit () at fccfg.c:122 > > #11 0x72538121 in ??? () at /opt/openoffice4/program/libvcl.so > > ... > > > > Note that libexpat.so.1 is in /usr/lib64, i.e. it is the ``system'' > > version, delivered by openSUSE. > > > > I could fix the issue on my own AOO41X builds by adding parameter > > --with-system-expat to the configure script. See commit > > 8ab1c45d01e8d22fb3a8e12992ebfcb53306f3c2 to the openoffice-devtools > > repository. > > > > I think that the above parameter is not given to the RC binaries? > > Jim, could you please confirm? > > You can find the build parameters here: > > https://github.com/apache/openoffice-devtools/tree/main/build-scripts/4.1.16 You are right! I forgot to "git fetch"... sorry. Best regards, -- Arrigo - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: AOO 4.1.16-RC3 libexpat-related crash on openSUSE
On Sun, Oct 12, 2025 at 8:05 PM Arrigo Marchiori wrote: > Hello All, > > I looked into the way expat is built and used in AOO. > > TL;DR: expat functions are partially taken from our expat, and > partially from system-level expat. > > On Sun, Oct 12, 2025 at 09:31:57AM +0200, Arrigo Marchiori wrote: > > > Hello All, > > > > On Sat, Oct 11, 2025 at 05:52:08PM +, Damjan Jovanovic wrote: > > > > > This seems like a problem with fontconfig's use of expat? > > According to the official build scripts, our own version of expat is > built in the main/expat module, and then it is _statically_ linked > where it is necessary. > > Fontconfig, on the other hand, is accessed as a shared library. > > Fontconfig needs expat. It is linked to it dynamically, at least on > openSUSE, and that would make sense everywhere IMHO. > > I had gdb break on function XML_ParserCreate(), that is one of the > expat initializator functions. It is first called by fontconfig, when > our vcl module initializes it. > > gdb breaks on the implementation of XML_ParserCreate() in > /usr/lib64/libexpat.so, that is the system-level expat dynamic > library. As explained above, this makes sense, because it's being > called by fontconfig, that is another system-level dynamic library. > > Function XML_ParserCreate() is very simple: it just calls > XML_ParserCreate_MM(), that is another function defined in the same > file of the expat source code. > > The problem is that, on my system, this function > XML_ParserCreate_MM(), called from the system-level dynamic library, > is not taken from the same system-level dynamic library > /usr/lib64/libexpat.so, but rather from AOO's > openoffice4/program/libhelplinker.so That is: an implementation from > our own statically linked expat. > > In other words, we are mixing pieces of the system-level expat, with > pieces of our own version of expat, that are taken from one of our .so > libraries, where they are statically linked. > > This explains why the configure script parameter --with-system-expat > solves the crash: all references to expat from AOO and fontconfig > point to the same, system-level dynamic library. There is only one > expat library and no conflicts or mix-ups are possible. > > The real crash is due to an unitialized parameter in the "parser" > structure that is constructed by function XML_ParserCreate(). I think > that the details are not important: the important issue is that the > two expat implementations are being confused and mixed with each > other. > > Why is the system-level libexpat.so calling internal functions of our > own statically linked expat? How can we avoid it? > Try running AOO as: LD_PRELOAD=/path/to/system/libexpat.so soffice.bin Does that crash? > > Thank you in advance and best regards, > -- > Arrigo > > Regards Damjan
Re: AOO 4.1.16-RC3 libexpat-related crash on openSUSE
Hello All, On Sat, Oct 11, 2025 at 05:52:08PM +, Damjan Jovanovic wrote: > This seems like a problem with fontconfig's use of expat? I should have investigated this issue better, the moment it appeared. My commit to openoffice-devtools is from last February. Something must have happened on OpenSUSE Leap 15.6 some (weeks?) before that date. Today I tried downloading the official binaries of AOO 4.1.14 and 4.1.15: they all crash. I must have used my own build of AOO on my system since February... unfortunately, I wiped it before I could check. I am trying to understand if there is an issue with our use of expat or not. In fact, Jim's build log says: > configure:14228: checking which expat to use > configure:14459: result: internal and: > SYSTEM_EXPAT='NO' However, libexpat.so is *not* included in the build -- not in the RPM's, for the least. This could be the problem. What do you think? > On Sat, Oct 11, 2025 at 1:15 PM Arrigo Marchiori wrote: > > > Dear All, > > > > I am seeing AOO 4.1.16-RC3 crash on openSUSE due to an issue with libexpat. > > > > Stack trace (I have debug symbols installed for fontconfig): > > #0 0x in ??? () > > #1 0x764fddde in ??? () at /usr/lib64/libexpat.so.1 > > #2 0x765022fc in XML_ParseBuffer () at /usr/lib64/libexpat.so.1 > > #3 0x76c562e4 in FcConfigParseAndLoadFromMemoryInternal > > (config=config@entry=0x712eb0, filename=filename@entry=0x7130f0 > > "/etc/fonts/fonts.conf", buffer=, complain=complain@entry=1, > > load=load@entry=1) at fcxml.c:3547 > > #4 0x76c56941 in _FcConfigParse > > (config=config@entry=0x712eb0, name=name@entry=0x0, > > complain=complain@entry=1, load=load@entry=1) at fcxml.c:3682 > > #5 0x76c591da in IA__FcConfigParseAndLoad > > (config=config@entry=0x712eb0, name=name@entry=0x0, > > complain=complain@entry=1) at fcxml.c:3719 > > #6 0x76c472a8 in FcInitLoadOwnConfig (config=0x712eb0, > > config@entry=0x0) at fcinit.c:89 > > #7 0x76c47506 in FcInitLoadOwnConfigAndFonts (config=config@entry > > =0x0) > > at fcinit.c:170 > > #8 0x76c47534 in IA__FcInitLoadConfigAndFonts () at fcinit.c:184 > > #9 0x76c38916 in FcConfigEnsure () at fccfg.c:96 > > #10 0x76c38979 in FcConfigInit () at fccfg.c:122 > > #11 0x72538121 in ??? () at /opt/openoffice4/program/libvcl.so > > ... > > > > Note that libexpat.so.1 is in /usr/lib64, i.e. it is the ``system'' > > version, delivered by openSUSE. > > > > I could fix the issue on my own AOO41X builds by adding parameter > > --with-system-expat to the configure script. See commit > > 8ab1c45d01e8d22fb3a8e12992ebfcb53306f3c2 to the openoffice-devtools > > repository. [...] -- Arrigo - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: AOO 4.1.16-RC3 libexpat-related crash on openSUSE
Hello All, I looked into the way expat is built and used in AOO. TL;DR: expat functions are partially taken from our expat, and partially from system-level expat. On Sun, Oct 12, 2025 at 09:31:57AM +0200, Arrigo Marchiori wrote: > Hello All, > > On Sat, Oct 11, 2025 at 05:52:08PM +, Damjan Jovanovic wrote: > > > This seems like a problem with fontconfig's use of expat? According to the official build scripts, our own version of expat is built in the main/expat module, and then it is _statically_ linked where it is necessary. Fontconfig, on the other hand, is accessed as a shared library. Fontconfig needs expat. It is linked to it dynamically, at least on openSUSE, and that would make sense everywhere IMHO. I had gdb break on function XML_ParserCreate(), that is one of the expat initializator functions. It is first called by fontconfig, when our vcl module initializes it. gdb breaks on the implementation of XML_ParserCreate() in /usr/lib64/libexpat.so, that is the system-level expat dynamic library. As explained above, this makes sense, because it's being called by fontconfig, that is another system-level dynamic library. Function XML_ParserCreate() is very simple: it just calls XML_ParserCreate_MM(), that is another function defined in the same file of the expat source code. The problem is that, on my system, this function XML_ParserCreate_MM(), called from the system-level dynamic library, is not taken from the same system-level dynamic library /usr/lib64/libexpat.so, but rather from AOO's openoffice4/program/libhelplinker.so That is: an implementation from our own statically linked expat. In other words, we are mixing pieces of the system-level expat, with pieces of our own version of expat, that are taken from one of our .so libraries, where they are statically linked. This explains why the configure script parameter --with-system-expat solves the crash: all references to expat from AOO and fontconfig point to the same, system-level dynamic library. There is only one expat library and no conflicts or mix-ups are possible. The real crash is due to an unitialized parameter in the "parser" structure that is constructed by function XML_ParserCreate(). I think that the details are not important: the important issue is that the two expat implementations are being confused and mixed with each other. Why is the system-level libexpat.so calling internal functions of our own statically linked expat? How can we avoid it? Thank you in advance and best regards, -- Arrigo - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: AOO 4.1.16-RC3 libexpat-related crash on openSUSE
Hello Damjan, All, On Tue, Oct 14, 2025 at 07:25:56PM +, Damjan Jovanovic wrote: > On Mon, Oct 13, 2025 at 8:08 PM Arrigo Marchiori wrote: > > > Hello All, > > > > On Mon, Oct 13, 2025 at 09:03:27AM +0200, Arrigo Marchiori wrote: > > > > > Hello Damjan, All, > > > > > > On Mon, Oct 13, 2025 at 03:01:33AM +, Damjan Jovanovic wrote: > > > > > > > On Sun, Oct 12, 2025 at 8:05 PM Arrigo Marchiori > > wrote: > > > > > > > > > Hello All, > > > > > > > > > > I looked into the way expat is built and used in AOO. > > > > > > > > > > TL;DR: expat functions are partially taken from our expat, and > > > > > partially from system-level expat. > > > > > > > > [...] > > > > > > > > > > Why is the system-level libexpat.so calling internal functions of our > > > > > own statically linked expat? How can we avoid it? > > > > > > > > Try running AOO as: > > > > LD_PRELOAD=/path/to/system/libexpat.so soffice.bin > > > > > > > > Does that crash? > > > > > > I will try later from home. > > > > I tried on my openSUSE Leap 15.6 system at home, and I confirm it > > crashes. Function XML_ParserCreate_MM is resolved to the wrong .so > > library. > > > > But: if I set LD_PRELOAD=/path/to/system/libexpat.so as you suggested, > > then AOO starts and runs successfully. > > > > > Then I know what the problem is: the ELF binary format's abysmal dynamic > linking process. > > In both Windows's PE binary format and MacOS's Mach-O binary format, at > link time, the binary being linked will store for each symbol, which > library that symbol is in. At run time, the symbol is only searched for in > the library that it was found in at link time. Whichever libraries load in > whichever order, symbols are only looked up where they should be. > > In *nix's ELF binary format, each binary contains a list of symbols, and a > list of libraries, with no relationship between them. At run time, missing > symbols are looked up in all libraries loaded for that entire process (not > just your child libraries), in the order the libraries were loaded. > > For a small application with few dependencies, this isn't too much of a > problem, as symbols aren't often duplicated between libraries. But for a > large application, especially one loading unpredictable libraries at run > time (like we do with UNO), it is quite possible for symbols to wrongly > match an unintended library, such a different version of the same library > that was loaded by someone else. > > That's exactly what's happening in your case: the internal expat is > statically linked into libhelplinker.so but its symbols are exported, > and libhelplinker.so is loaded before fontconfig and system expat, so > fontconfig's expat symbols are resolved against libhelplinker.so instead of > expat. When you LD_PRELOAD the system expat, it loads first, and > supersedes libhelplinker.so's expat symbols. > > If it's not possible to avoid loading both our expat and system expat, then > one of the following should fix the problem: > 1. Link expat statically but hide its symbols, presumably by using a linker > map file (libhelplinker.so already uses -fvisibility=hidden, but I don't > think that's enough, expat would need to use that too). We do link expat statically. On Linux, it is compiled with -fvisibility=hidden. > 2. Use custom ELF symbol versioning on our expat, so it can co-exist in > memory with the system expat, but our binaries will only use our expat and > other binaries will only use the system expat. This again requires a linker > map file. This would be clever! But should we change our sources to use the customized expat? If so, this would remove the possibility to use system-level expat, wouldn't it? > 3. Platform-specific hacks, like run-time dynamic linking with the > RTLD_DEEPBIND flag to dlopen() (Linux and FreeBSD), or linking with > -Bdirect on Solaris. The issue seems to only happen on openSUSE Leap 15.6, so it may not be worth such a hack. Thank you for your insights. Best regards, -- Arrigo - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: AOO 4.1.16-RC3 libexpat-related crash on openSUSE
Hi Arrigo, All, I can talk about the python part, there I had the issue that you could not build against an external python, even if you configured that you want to build against a system- build. Configure was always using the internal config too. The build was licky because configure overwrites the external configs. i could imagine that the implementation of configure for expat is not clean either. All the best Peter Am 13. Oktober 2025 09:03:27 MESZ schrieb Arrigo Marchiori : >Hello Damjan, All, > >On Mon, Oct 13, 2025 at 03:01:33AM +, Damjan Jovanovic wrote: > >> On Sun, Oct 12, 2025 at 8:05 PM Arrigo Marchiori wrote: >> >> > Hello All, >> > >> > I looked into the way expat is built and used in AOO. >> > >> > TL;DR: expat functions are partially taken from our expat, and >> > partially from system-level expat. >> > >[...] >> > >> > Why is the system-level libexpat.so calling internal functions of our >> > own statically linked expat? How can we avoid it? >> >> Try running AOO as: >> LD_PRELOAD=/path/to/system/libexpat.so soffice.bin >> >> Does that crash? > >I will try later from home. > >In the meantime, I fired up a VM with the lates OpenSUSE at work >and... it works well here! > >I could have done something wrong on my own system at home. I'll look >into that later. I wanted to share with you this... relieving >information. > >Best regards, >-- >Arrigo > >- >To unsubscribe, e-mail: [email protected] >For additional commands, e-mail: [email protected] >
Re: AOO 4.1.16-RC3 libexpat-related crash on openSUSE
Hi Arrigo, Am 11.10.25 um 15:15 schrieb Arrigo Marchiori: Dear All, I am seeing AOO 4.1.16-RC3 crash on openSUSE due to an issue with libexpat. Stack trace (I have debug symbols installed for fontconfig): #0 0x in ??? () #1 0x764fddde in ??? () at /usr/lib64/libexpat.so.1 #2 0x765022fc in XML_ParseBuffer () at /usr/lib64/libexpat.so.1 #3 0x76c562e4 in FcConfigParseAndLoadFromMemoryInternal (config=config@entry=0x712eb0, filename=filename@entry=0x7130f0 "/etc/fonts/fonts.conf", buffer=, complain=complain@entry=1, load=load@entry=1) at fcxml.c:3547 #4 0x76c56941 in _FcConfigParse (config=config@entry=0x712eb0, name=name@entry=0x0, complain=complain@entry=1, load=load@entry=1) at fcxml.c:3682 #5 0x76c591da in IA__FcConfigParseAndLoad (config=config@entry=0x712eb0, name=name@entry=0x0, complain=complain@entry=1) at fcxml.c:3719 #6 0x76c472a8 in FcInitLoadOwnConfig (config=0x712eb0, config@entry=0x0) at fcinit.c:89 #7 0x76c47506 in FcInitLoadOwnConfigAndFonts (config=config@entry=0x0) at fcinit.c:170 #8 0x76c47534 in IA__FcInitLoadConfigAndFonts () at fcinit.c:184 #9 0x76c38916 in FcConfigEnsure () at fccfg.c:96 #10 0x76c38979 in FcConfigInit () at fccfg.c:122 #11 0x72538121 in ??? () at /opt/openoffice4/program/libvcl.so ... Note that libexpat.so.1 is in /usr/lib64, i.e. it is the ``system'' version, delivered by openSUSE. I could fix the issue on my own AOO41X builds by adding parameter --with-system-expat to the configure script. See commit 8ab1c45d01e8d22fb3a8e12992ebfcb53306f3c2 to the openoffice-devtools repository. I think that the above parameter is not given to the RC binaries? Jim, could you please confirm? You can find the build parameters here: https://github.com/apache/openoffice-devtools/tree/main/build-scripts/4.1.16 Regards, Matthias Are we building our own version of libexpat in the official builds? If so, then we shall also ship it in binary form... shall we not? I apologize for not having reported this on former RC builds. Thank you in advance and best regards, -- Arrigo - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: AOO 4.1.16-RC3 libexpat-related crash on openSUSE
On Mon, Oct 13, 2025 at 8:08 PM Arrigo Marchiori wrote: > Hello All, > > On Mon, Oct 13, 2025 at 09:03:27AM +0200, Arrigo Marchiori wrote: > > > Hello Damjan, All, > > > > On Mon, Oct 13, 2025 at 03:01:33AM +, Damjan Jovanovic wrote: > > > > > On Sun, Oct 12, 2025 at 8:05 PM Arrigo Marchiori > wrote: > > > > > > > Hello All, > > > > > > > > I looked into the way expat is built and used in AOO. > > > > > > > > TL;DR: expat functions are partially taken from our expat, and > > > > partially from system-level expat. > > > > > > [...] > > > > > > > > Why is the system-level libexpat.so calling internal functions of our > > > > own statically linked expat? How can we avoid it? > > > > > > Try running AOO as: > > > LD_PRELOAD=/path/to/system/libexpat.so soffice.bin > > > > > > Does that crash? > > > > I will try later from home. > > I tried on my openSUSE Leap 15.6 system at home, and I confirm it > crashes. Function XML_ParserCreate_MM is resolved to the wrong .so > library. > > But: if I set LD_PRELOAD=/path/to/system/libexpat.so as you suggested, > then AOO starts and runs successfully. > > Then I know what the problem is: the ELF binary format's abysmal dynamic linking process. In both Windows's PE binary format and MacOS's Mach-O binary format, at link time, the binary being linked will store for each symbol, which library that symbol is in. At run time, the symbol is only searched for in the library that it was found in at link time. Whichever libraries load in whichever order, symbols are only looked up where they should be. In *nix's ELF binary format, each binary contains a list of symbols, and a list of libraries, with no relationship between them. At run time, missing symbols are looked up in all libraries loaded for that entire process (not just your child libraries), in the order the libraries were loaded. For a small application with few dependencies, this isn't too much of a problem, as symbols aren't often duplicated between libraries. But for a large application, especially one loading unpredictable libraries at run time (like we do with UNO), it is quite possible for symbols to wrongly match an unintended library, such a different version of the same library that was loaded by someone else. That's exactly what's happening in your case: the internal expat is statically linked into libhelplinker.so but its symbols are exported, and libhelplinker.so is loaded before fontconfig and system expat, so fontconfig's expat symbols are resolved against libhelplinker.so instead of expat. When you LD_PRELOAD the system expat, it loads first, and supersedes libhelplinker.so's expat symbols. If it's not possible to avoid loading both our expat and system expat, then one of the following should fix the problem: 1. Link expat statically but hide its symbols, presumably by using a linker map file (libhelplinker.so already uses -fvisibility=hidden, but I don't think that's enough, expat would need to use that too). 2. Use custom ELF symbol versioning on our expat, so it can co-exist in memory with the system expat, but our binaries will only use our expat and other binaries will only use the system expat. This again requires a linker map file. 3. Platform-specific hacks, like run-time dynamic linking with the RTLD_DEEPBIND flag to dlopen() (Linux and FreeBSD), or linking with -Bdirect on Solaris. I believe this is one of the reasons Linux has failed on the desktop: with ELF's disasterous symbol search algorithm, it is impossible to make reliable software that works everywhere. Some version of some library on some distribution will pull in some incompatible symbol -> crash. Only monolithic bloated container solutions like Snap and Flatpak avoid that problem, by controlling the entire filesystem, so no unexpected library can come in. Regards Damjan
Re: AOO 4.1.16-RC3 libexpat-related crash on openSUSE
Hello All, On Mon, Oct 13, 2025 at 09:03:27AM +0200, Arrigo Marchiori wrote: > Hello Damjan, All, > > On Mon, Oct 13, 2025 at 03:01:33AM +, Damjan Jovanovic wrote: > > > On Sun, Oct 12, 2025 at 8:05 PM Arrigo Marchiori wrote: > > > > > Hello All, > > > > > > I looked into the way expat is built and used in AOO. > > > > > > TL;DR: expat functions are partially taken from our expat, and > > > partially from system-level expat. > > > > [...] > > > > > > Why is the system-level libexpat.so calling internal functions of our > > > own statically linked expat? How can we avoid it? > > > > Try running AOO as: > > LD_PRELOAD=/path/to/system/libexpat.so soffice.bin > > > > Does that crash? > > I will try later from home. I tried on my openSUSE Leap 15.6 system at home, and I confirm it crashes. Function XML_ParserCreate_MM is resolved to the wrong .so library. But: if I set LD_PRELOAD=/path/to/system/libexpat.so as you suggested, then AOO starts and runs successfully. After it ran successfully, then on next runs, function XML_ParserCreate_MM is called from a secondary thread (probably something has changed in the configuration) and... it works! So, AOO only crashes until I manage to run it successfully _once_. Then it will always start successfully. > In the meantime, I fired up a VM with the lates OpenSUSE at work > and... it works well here! > > I could have done something wrong on my own system at home. I created another user on my system, and it shows the same behavior. I must try with a fresh install of openSUSE 15.6 to understand if it is a problem of my system or of that distribution in general. (I am reluctant to upgrade to openSUSE 16 because it does not seem to ship certain packages that are required for AOO development... more on this later). Best regards, -- Arrigo - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: AOO 4.1.16-RC3 libexpat-related crash on openSUSE
Hello Damjan, All, On Mon, Oct 13, 2025 at 03:01:33AM +, Damjan Jovanovic wrote: > On Sun, Oct 12, 2025 at 8:05 PM Arrigo Marchiori wrote: > > > Hello All, > > > > I looked into the way expat is built and used in AOO. > > > > TL;DR: expat functions are partially taken from our expat, and > > partially from system-level expat. > > [...] > > > > Why is the system-level libexpat.so calling internal functions of our > > own statically linked expat? How can we avoid it? > > Try running AOO as: > LD_PRELOAD=/path/to/system/libexpat.so soffice.bin > > Does that crash? I will try later from home. In the meantime, I fired up a VM with the lates OpenSUSE at work and... it works well here! I could have done something wrong on my own system at home. I'll look into that later. I wanted to share with you this... relieving information. Best regards, -- Arrigo - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: AOO 4.1.16-RC3 libexpat-related crash on openSUSE
This seems like a problem with fontconfig's use of expat? Damjan On Sat, Oct 11, 2025 at 1:15 PM Arrigo Marchiori wrote: > Dear All, > > I am seeing AOO 4.1.16-RC3 crash on openSUSE due to an issue with libexpat. > > Stack trace (I have debug symbols installed for fontconfig): > #0 0x in ??? () > #1 0x764fddde in ??? () at /usr/lib64/libexpat.so.1 > #2 0x765022fc in XML_ParseBuffer () at /usr/lib64/libexpat.so.1 > #3 0x76c562e4 in FcConfigParseAndLoadFromMemoryInternal > (config=config@entry=0x712eb0, filename=filename@entry=0x7130f0 > "/etc/fonts/fonts.conf", buffer=, complain=complain@entry=1, > load=load@entry=1) at fcxml.c:3547 > #4 0x76c56941 in _FcConfigParse > (config=config@entry=0x712eb0, name=name@entry=0x0, > complain=complain@entry=1, load=load@entry=1) at fcxml.c:3682 > #5 0x76c591da in IA__FcConfigParseAndLoad > (config=config@entry=0x712eb0, name=name@entry=0x0, > complain=complain@entry=1) at fcxml.c:3719 > #6 0x76c472a8 in FcInitLoadOwnConfig (config=0x712eb0, > config@entry=0x0) at fcinit.c:89 > #7 0x76c47506 in FcInitLoadOwnConfigAndFonts (config=config@entry > =0x0) > at fcinit.c:170 > #8 0x76c47534 in IA__FcInitLoadConfigAndFonts () at fcinit.c:184 > #9 0x76c38916 in FcConfigEnsure () at fccfg.c:96 > #10 0x76c38979 in FcConfigInit () at fccfg.c:122 > #11 0x72538121 in ??? () at /opt/openoffice4/program/libvcl.so > ... > > Note that libexpat.so.1 is in /usr/lib64, i.e. it is the ``system'' > version, delivered by openSUSE. > > I could fix the issue on my own AOO41X builds by adding parameter > --with-system-expat to the configure script. See commit > 8ab1c45d01e8d22fb3a8e12992ebfcb53306f3c2 to the openoffice-devtools > repository. > > I think that the above parameter is not given to the RC binaries? > Jim, could you please confirm? > > Are we building our own version of libexpat in the official builds? If > so, then we shall also ship it in binary form... shall we not? > > I apologize for not having reported this on former RC builds. > > Thank you in advance and best regards, > -- > Arrigo > > - > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
