Bug 1306162

Summary: 'jade' segfaults during PostgreSQL package build (postgres's ftbfs)
Product: [Fedora] Fedora Reporter: Pavel Raiskup <praiskup>
Component: openjadeAssignee: Ondrej Vasik <ovasik>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: kdudka, ovasik, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-02-15 22:36:22 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Reproducer none

Description Pavel Raiskup 2016-02-10 08:23:17 UTC
Created attachment 1122692 [details]
Reproducer

With simplified reproducer (attached), the output is:

$ docbook2txt -d ./style.dsl ./test.sgml 
Using catalogs: /etc/sgml/sgml-docbook-4.1.cat
Using stylesheet: /builddir/build/BUILD/postgresql-9.5.1/postgresql-setup-4.0/report/./style.dsl
Working on: /builddir/build/BUILD/postgresql-9.5.1/postgresql-setup-4.0/report/./test.sgml
jade:/builddir/build/BUILD/postgresql-9.5.1/postgresql-setup-4.0/report/./test.sgml:10:9:E: end tag for "ARTICLE" which is not finished
/usr/share/sgml/docbook/utils-0.6.14/backends/txt: line 28: 27550 Segmentation fault      (core dumped) $SGML_JADE -V nochunks -t sgml ${SGML_ARGUMENTS} "$SGML_FILE" > ${HTML}

Note that this is reproduced in 'fedora-rawhide-x86_64' mock on fedora-23-x86_64
virtual machine (which is what is on koji and copr builders).

Backtrace:
(gdb) bt
#0  Collector::DynamicRoot::link (root=0x5646ae0aaba8, this=0x7ffd14dd3b80) at Collector.h:170
#1  Collector::DynamicRoot::DynamicRoot (c=..., this=0x7ffd14dd3b80) at Collector.h:184
#2  OpenJade_DSSSL::ELObjDynamicRoot::ELObjDynamicRoot (obj=0x5646ae096c90, c=..., this=0x7ffd14dd3b80) at Interpreter.h:265
#3  OpenJade_DSSSL::SchemeParser::parseDatum (this=this@entry=0x7ffd14dd4470, otherAllowed=otherAllowed@entry=16, result=@0x7ffd14dd3c28: 0x0, loc=..., tok=@0x7ffd14dd3dd8: OpenJade_DSSSL::SchemeParser::tokenString)
    at SchemeParser.cxx:1587
#4  0x00007f500244c4e5 in OpenJade_DSSSL::SchemeParser::parseDatum (this=this@entry=0x7ffd14dd4470, otherAllowed=otherAllowed@entry=0, result=@0x7ffd14dd3cd8: 0x0, loc=..., tok=@0x7ffd14dd3dd8: OpenJade_DSSSL::SchemeParser::tokenString)
    at SchemeParser.cxx:1581
#5  0x00007f500244d898 in OpenJade_DSSSL::SchemeParser::parseExpression (this=this@entry=0x7ffd14dd4470, allowed=allowed@entry=0, expr=..., key=@0x7ffd14dd3ddc: OpenJade_DSSSL::Identifier::notKey, 
    tok=@0x7ffd14dd3dd8: OpenJade_DSSSL::SchemeParser::tokenString) at SchemeParser.cxx:796
#6  0x00007f5002452f8a in OpenJade_DSSSL::SchemeParser::parseMake (this=this@entry=0x7ffd14dd4470, expr=...) at SchemeParser.cxx:1333
#7  0x00007f500244db01 in OpenJade_DSSSL::SchemeParser::parseExpression (this=this@entry=0x7ffd14dd4470, allowed=allowed@entry=0, expr=..., key=@0x7ffd14dd3f64: OpenJade_DSSSL::Identifier::keyMake, 
    tok=@0x7ffd14dd3f60: OpenJade_DSSSL::SchemeParser::tokenIdentifier) at SchemeParser.cxx:856
#8  0x00007f5002454188 in OpenJade_DSSSL::SchemeParser::parseBindingsAndBody1 (this=this@entry=0x7ffd14dd4470, vars=..., inits=..., body=...) at SchemeParser.cxx:1547
#9  0x00007f50024542ca in OpenJade_DSSSL::SchemeParser::parseBindingsAndBody (this=this@entry=0x7ffd14dd4470, vars=..., inits=..., body=...) at SchemeParser.cxx:1529
#10 0x00007f50024543bb in OpenJade_DSSSL::SchemeParser::parseLetStar (this=this@entry=0x7ffd14dd4470, expr=...) at SchemeParser.cxx:1504
#11 0x00007f500244dbbf in OpenJade_DSSSL::SchemeParser::parseExpression (this=this@entry=0x7ffd14dd4470, allowed=allowed@entry=0, expr=..., key=@0x7ffd14dd41ac: OpenJade_DSSSL::Identifier::keyLetStar, 
    tok=@0x7ffd14dd41a8: OpenJade_DSSSL::SchemeParser::tokenIdentifier) at SchemeParser.cxx:844
#12 0x00007f50024518eb in OpenJade_DSSSL::SchemeParser::parseBegin (this=this@entry=0x7ffd14dd4470, expr=...) at SchemeParser.cxx:1252
#13 0x00007f5002453e7e in OpenJade_DSSSL::SchemeParser::doDefine (this=this@entry=0x7ffd14dd4470) at SchemeParser.cxx:689
#14 0x00007f500245556f in OpenJade_DSSSL::SchemeParser::parse (this=this@entry=0x7ffd14dd4470) at SchemeParser.cxx:141
#15 0x00007f500245aa48 in OpenJade_DSSSL::StyleEngine::parseSpec (this=this@entry=0x7ffd14dd45e0, specParser=..., charset=..., id=..., mgr=...) at StyleEngine.cxx:101
#16 0x00007f50023f51f4 in OpenJade_DSSSL::DssslApp::processGrove (this=0x7ffd14dd47d0) at DssslApp.cxx:352
#17 0x00007f5002080a8f in OpenSP::GroveApp::generateEvents (this=0x7ffd14dd47d0, eceh=<optimized out>) at GroveApp.cxx:36
#18 0x00007f50023f556e in OpenJade_DSSSL::DssslApp::processSysid (this=0x7ffd14dd47d0, sysid=...) at DssslApp.cxx:91
#19 0x00007f50027ec582 in OpenSP::EntityApp::processArguments (this=0x7ffd14dd47d0, argc=<optimized out>, argv=<optimized out>) at EntityApp.cxx:82
#20 0x00007f50027db9b9 in OpenSP::CmdLineApp::run (this=0x7ffd14dd47d0, argc=12, argv=0x7ffd14dd4ce8) at CmdLineApp.cxx:356
#21 0x00005646ac30c59b in main (argc=12, argv=0x7ffd14dd4ce8) at jade.cxx:192

(coredump in tarball)

Comment 1 Pavel Raiskup 2016-02-10 08:36:16 UTC
Code snippet:

 │163     inline
 │164     void Collector::DynamicRoot::link(const DynamicRoot *root)
 │165     {
 │166       DynamicRoot *list = (DynamicRoot *)root;
 │167       // link in just after list
 │168       prev_ = list;
 │169       next_ = list->next_;
>│170       list->next_->prev_ = this;
 │171       list->next_ = this;
 │172     }

Gdb says:

(gdb) p *list
$5 = {_vptr.DynamicRoot = 0x2, next_ = 0x2, prev_ = 0x5646ae123370}

So probably uninitialized 'list->next_', but I don't understand much the code.

Comment 2 Pavel Raiskup 2016-02-10 21:07:50 UTC
Turning off the optimizations works for me:

 %build
 cp -p %{SOURCE2} %{SOURCE3} config/
+export CFLAGS="-O0 -g3" CXXFLAGS="-O0 -g3"
 %configure --disable-static --datadir=%{_datadir}/sgml/%{name}-%{version} \

Which seems like this is related to gcc-6.0.0 update.

Comment 3 Pavel Raiskup 2016-02-11 13:26:46 UTC
After nontrivial amount of time spent in debugging I'm giving up :(.  This
requires someone who knows how to debug the internal memory management to
clearly say whether jade or GCC is wrong.

In any case, having the '-ftree-dse' disabled (-fno-tree-dse in CXXFLAGS)
works-around this issue, from man(1) g++:

   -ftree-dse
       Perform dead store elimination (DSE) on trees.  A dead store is a
       store into a memory location that is later overwritten by another
       store without any intervening loads.  In this case the earlier
       store can be deleted.  This flag is enabled by default at -O and
       higher.

Comment 4 Pavel Raiskup 2016-02-11 15:59:23 UTC
Work-around pushed (and built) as:
http://pkgs.fedoraproject.org/cgit/rpms/openjade.git/commit/?id=f54460eb607fa

PostgreSQL build succeeded against the patched version:
http://koji.fedoraproject.org/koji/buildinfo?buildID=734974

It is not a real fix -- please keep opened.

Comment 5 Kamil Dudka 2016-02-15 16:50:59 UTC
GCC upstream explains why this is a bug in openjade's code:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69534#c9

As fixing the code would be non-trivial, using the -fno-lifetime-dse compilation flag sounds like a good enough solution to this bug.