Comment 14 for bug 1869734

Revision history for this message
Christian Ehrhardt  (paelzer) wrote : Re: openjade segfaults on arm (due to gcc optimization)

Backtrace is more readable now, erase comes from resize it seems.

#0 0x0000fffff7e4f620 in OpenSP::NCVector<OpenSP::Owner<OpenJade_DSSSL::Expression> >::erase (this=0xffffffffe0c8, p1=0xaaaaab46eaf0, p2=0xaaaaab46eb00)
    at /usr/include/OpenSP/Vector.cxx:132
#1 0x0000fffff7e4e0e4 in OpenSP::NCVector<OpenSP::Owner<OpenJade_DSSSL::Expression> >::resize (this=0xffffffffe0c8, n=1) at /usr/include/OpenSP/Vector.h:29
#2 0x0000fffff7ec9ee0 in OpenJade_DSSSL::SchemeParser::parseExpression (this=0xffffffffe538, allowed=16, expr=..., key=@0xffffffffe1cc: OpenJade_DSSSL::Identifier::notKey,
    tok=@0xffffffffe1c8: OpenJade_DSSSL::SchemeParser::tokenCloseParen) at SchemeParser.cxx:1004
#3 0x0000fffff7ec9e8c in OpenJade_DSSSL::SchemeParser::parseExpression (this=0xffffffffe538, allowed=0, expr=..., key=@0xffffffffe1cc: OpenJade_DSSSL::Identifier::notKey,
    tok=@0xffffffffe1c8: OpenJade_DSSSL::SchemeParser::tokenCloseParen) at SchemeParser.cxx:1001
#4 0x0000fffff7eccdd0 in OpenJade_DSSSL::SchemeParser::parseBegin (this=0xffffffffe538, expr=...) at SchemeParser.cxx:1551
#5 0x0000fffff7eccc54 in OpenJade_DSSSL::SchemeParser::parseBody (this=0xffffffffe538, expr=...) at SchemeParser.cxx:1539
#6 0x0000fffff7ec92c8 in OpenJade_DSSSL::SchemeParser::parseDefine (this=0xffffffffe538, ident=@0xffffffffe3d8: 0xaaaaab4827f0, expr=...) at SchemeParser.cxx:861
#7 0x0000fffff7ec8ed0 in OpenJade_DSSSL::SchemeParser::doDefine (this=0xffffffffe538) at SchemeParser.cxx:814
#8 0x0000fffff7ec5f98 in OpenJade_DSSSL::SchemeParser::parse (this=0xffffffffe538) at SchemeParser.cxx:172
#9 0x0000fffff7e9b2d8 in OpenJade_DSSSL::Interpreter::installBuiltins (this=0xaaaaaacf1b50) at Interpreter.cxx:2093
#10 0x0000fffff7e93448 in OpenJade_DSSSL::Interpreter::Interpreter (this=0xaaaaaacf1b50, groveManager=0xffffffffed00, messenger=0xffffffffea50, unitsPerInch=72000, debugMode=false,
    dsssl2=false, style=true, strictMode=false, fotbDescr=...) at Interpreter.cxx:162
#11 0x0000fffff7edb1b8 in OpenJade_DSSSL::StyleEngine::parseSpec (this=0xaaaaaabdae80, specParser=..., charset=..., id=..., mgr=..., defVars=...) at StyleEngine.cxx:85
#12 0x0000fffff7e2f784 in OpenJade_DSSSL::DssslApp::processSysid (this=0xffffffffea48, sysid=...) at DssslApp.cxx:138
#13 0x0000fffff7aaa9c8 in OpenSP::EntityApp::processArguments(int, char**) () from /lib/libosp.so.5
#14 0x0000fffff7a9add4 in OpenSP::CmdLineApp::run(int, char**) () from /lib/libosp.so.5

Also the line number is now correct on the access of pointer p and its destructor call:

line 132 is:
  ((X *)p)->~X();

(gdb) p p
$1 = (const OpenSP::Owner<OpenJade_DSSSL::Expression> *) 0xaaaaab46eb00

Also the passed pointers are intact:
(gdb) p p1
$6 = (const OpenSP::Owner<OpenJade_DSSSL::Expression> *) 0xaaaaab46eaf0
(gdb) p p2
$7 = (const OpenSP::Owner<OpenJade_DSSSL::Expression> *) 0xaaaaab46eb00

The pointers indicate that we are at p2 already.

And that is odd compared to p1.
(gdb) p *p1
$9 = {_vptr.Owner = 0xfffff7f8a040 <vtable for OpenSP::Owner<OpenJade_DSSSL::Expression>+16>, p_ = 0x0}
(gdb) p *p2
$10 = {_vptr.Owner = 0x6c00000063, p_ = 0x1d1}

See how the _vptr.Owner has no reasonable type.

(gdb) ptype T
type = class OpenSP::Owner<OpenJade_DSSSL::Expression> [with T = OpenJade_DSSSL::Expression] {
  private:
    T *p_;

  public:
    Owner(void);
    Owner(T *);
  private:
    Owner(const OpenSP::Owner<T> &);
  public:
    ~Owner();
    void operator=(T *);
  private:
    void operator=(const OpenSP::Owner<T> &);
  public:
    operator int(void) const;
    T * pointer(void) const;
    T * operator->(void) const;
    T & operator*(void) const;
    void swap(OpenSP::Owner<T> &);
    T * extract(void);
    void clear(void);
  private:
    void del(void);
}

So the question is "why is p2 not a proper OpenSP::Owner<OpenJade_DSSSL::Expression object"