The call is from:
OpenSP::NCVector<OpenSP::Owner<OpenJade_DSSSL::Expression> >::resize
(this=0xffffffffe0c8, n=1)
That means resize it to size "1".
And it would be ok to delete all later elements.
void resize(size_t n) {
if (n < size_)
erase(ptr_ + n, ptr_ + size_);
else if (n > size_)
append(n - size_);
}
p ptr_
$14 = (OpenSP::Owner<OpenJade_DSSSL::Expression> *) 0xaaaaab46eae0
And therefore ptr_ + size_ => 0xaaaaab46eb00
But there is no valid OpenSP::Owner<OpenJade_DSSSL::Expression at this address.
999 for (;;) {
1000 args.resize(args.size() + 1);
1001 if (!parseExpression(allowCloseParen, args.back(), key, tok))
1002 return 0;
1003 if (!args.back()) {
1004 args.resize(args.size() - 1); <===
1005 break;
1006 }
1007 }
Here:
(gdb) p args
$16 = {_vptr.NCVector = 0xfffff7f8a020 <vtable for
OpenSP::NCVector<OpenSP::Owner<OpenJade_DSSSL::Expression> >+16>, size_ = 2,
ptr_ = 0xaaaaab46eae0, alloc_ = 2}
But the size is only "2" elements, not three.
(gdb) p *(args.ptr_+0)
$21 = {_vptr.Owner = 0xfffff7f8a040 <vtable for
OpenSP::Owner<OpenJade_DSSSL::Expression>+16>, p_ = 0xaaaaab46f9f0}
(gdb) p *(args.ptr_+1)
$22 = {_vptr.Owner = 0xfffff7f8a040 <vtable for
OpenSP::Owner<OpenJade_DSSSL::Expression>+16>, p_ = 0x0}
(gdb) p *(args.ptr_+2)
$23 = {_vptr.Owner = 0x6c00000063, p_ = 0x1d1}
b OpenJade_DSSSL::SchemeParser::parseExpression
b OpenSP::NCVector<OpenSP::Owner<OpenJade_DSSSL::Expression> >::resize
(gdb) p tok
$30 = (OpenJade_DSSSL::SchemeParser::Token &) @0xffffffffe1c8:
OpenJade_DSSSL::SchemeParser::tokenCloseParen
And I see him taking the route I'd expect then:
(gdb)
977 switch (tok) {
(gdb)
1090 break;
(gdb)
1092 return 1;
That is the default: in the switch a tokenCloseParen doesn't have an
entry.
But then it re-enters the switch without obvious reason.
1003 if (!args.back()) {
(gdb) l
998 NCVector<Owner<Expression> > args;
999 for (;;) {
1000 args.resize(args.size() + 1);
1001 if (!parseExpression(allowCloseParen, args.back(), key, tok))
1002 return 0;
1003 if (!args.back()) {
1004 args.resize(args.size() - 1);
1005 break;
1006 }
1007 }
It didn't pass lines 998-1002 at all, not do I see why it would jump up
here?
--
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
