If I run this with the -O0 build it never ever reaches OpenSP::Vector<OpenJade_DSSSL::ProcessingMode::Rule*>::erase So the code is still broken, but we just don't reach it. -O0 isn't even a good mitigation.
Tracking the root cause further. Very late in the -O0 build it then hits it like: ::erase (this=0xaaaaab027250, p1=0xaaaaaaeb5cf0, p2=0xaaaaaaeb5cf8) ::erase (this=0xaaaaab46cf10, p1=0xaaaaab883120, p2=0xaaaaab883128) ... All that looks reasonable. The other call we see in -O2 builds is broken: ::erase (p1=0x1, p2=0x2, ... But this is actually a header in: src:opensp Defines in /usr/include/OpenSP/Vector.cxx:331 for (const T *p = p1; p != p2; p++) # works on pointer p But for any type that does not surely increase the right way. E.g. p1 = 0x1, p2 = 0x2 but increment = 4 (due to pointer arithmetic) Then it will increment p forever. If we use <= it will stop as soon as we would run over. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to openjade in Ubuntu. https://bugs.launchpad.net/bugs/1869734 Title: openjade segfaults on arm (due to gcc optimization) Status in openjade package in Ubuntu: Triaged Bug description: <Myon> cpaelzer: fun, openjade segfaulting on focal/arm64 <cpaelzer> I beg your pardon for my ignorance of the ecosystem, but how is this related to postgresql-apt <cpaelzer> for doc generation? <Myon> cpaelzer: the postgresql-9.5 and -9.6 builds fail during doc generation on focal/arm64 <Myon> everything else (other archs, other dists) is fine <Myon> https://pgdgbuild.dus.dg-i.net/job/postgresql-9.5-binaries/architecture=arm64,distribution=focal/55/console <cpaelzer> Myon: only on arm64? <Myon> only there, yes <Myon> ./configure && make -C doc/src/sgml all should reproduce it <cpaelzer> clone and build this branch ? https://github.com/postgres/postgres/tree/REL9_5_STABLE <Myon> the crash is in /usr/lib/libostyle.so.1 from libostyle1c2 <cpaelzer> here it is <cpaelzer> segfault <Myon> I have this now http://paste.debian.net/1136839/ <cpaelzer> https://paste.ubuntu.com/p/CfzrfWkqzs/ <cpaelzer> well I wanted to get -O0 to see more int he debugger <cpaelzer> my build worked as well now <Myon> the -O0 openjade installed doesn't segfault <cpaelzer> oh so like my -O0 then <cpaelzer> so maybe we should just always -O0 openjade then? <cpaelzer> TBH who cares about optimization in that <cpaelzer> But its usage is mostly build time and not runtime <Myon> maybe -O0 on arm64 only <cpaelzer> I'm rebulding -O2 again to recheck if that really is it <cpaelzer> and then -O1 to check the in between <cpaelzer> it might "just" need a rebuild <cpaelzer> -O2 re-build segfault <cpaelzer> -O1 (for completeness) rebuild ... seems to hang? <Myon> probably not really relevant <cpaelzer> agreed, but I want to rebuild -O0 again just to see it builds and then works <cpaelzer> -O0 on arm64 really seems to be a good choice <Myon> I can try if rebuilding makes it fail on sid <Myon> cpaelzer: recompiling openjade in arm64/sid doesn't make it segfault <Myon> so it seems this needs a focal-only fix <Myon> cpaelzer: the openjade segfault is also present in pgpool2, so not just in ancient PostgreSQL :( To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openjade/+bug/1869734/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
