On 19.09.2021 22:06, Jakub Bogusz wrote: > On Sun, Sep 19, 2021 at 08:17:47PM +0200, Jan Rękorajski wrote: > > On Thu, 19 Aug 2021, Jakub Bogusz wrote: > > > > > On Wed, Aug 18, 2021 at 10:34:48PM +0200, Jan Rękorajski wrote: > > > > New builds of qt4 on i686 exhibit crashes (ex. linguist in avogadro), or > > > > infinite looping (ex. meinproc4 in kde4-kig). > > > > > > > > I'm running out of ideas[1] and time to troubleshoot this and would > > > > appreciate if anyone would be willing to try and figure out WTF is > > > > broken there. > > > > > > > > [1] neither -O0, nor -std=gnu98 seem to do the trick, it could be a > > > > glibc 2.34 issue, but I don't have resources at hand to validate it. > > > > > > I don't know yet if it's related to glibc, gcc or binutils, but simple > > > testcase is searching in empty QMap: > > > > > > ``` > > > #include <QtCore/QMap> > > > > > > int main() > > > { > > > QMap<int, std::string> mm; > > > mm.constFind(999); > > > } > > > ``` > > > > > > It hangs even on carme-x86_64. > > > > > > Issue is probably related to shared_null static field (SIOF?) > > > > My take is on gcc 11. I downgraded everything but gcc and it still crashed. > > > > To verify that it's indeed gcc I need to rebuild it (gcc) locally due to > > intertwined deps preventing simple package downgrade. > > I tried to investigate the issue deeper - and the last I found was: > > The symbol _ZN8QMapData11shared_nullE (demangled: QMapData::shared_null) > resides both in executable (objdump -T from i686): > > 0804c040 g DO .bss 00000048 Base _ZN8QMapData11shared_nullE > > and libQtCore.so.4: > > 002fa460 g DO .data 00000048 Base _ZN8QMapData11shared_nullE > > > When compiled in current Th, the code in executable sees symbol mapped > from executable and the library sees symbol mapped from library. > > IIRC when compiled on slightly older system (qt4 built with gcc 7 or 8, > glibc 2.33 etc.) in both cases symbol address was the same. > > But in my current system (i686, glibc-2.34, binutils-2.37, gcc-8.4.0, qt4 > rebuilt in this environment) the result is the same as in Th: there are > two instances of this symbol and testcase hangs.
Same findings here, workaround committed which makes avogadro compile successfully. Root cause of this behavior still to be determined though. _______________________________________________ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl