On Mon, Sep 22, 2014 at 08:10:24AM +0200, Pau Garcia i Quiles wrote:
> The vulnerability is solved in ace 6.2.7+dfsg-2
Thanks.
> Could you please look into the Doxygen 1.8.8 issue on amd64? It seems it
> does not happen on other architectures
| #0 Definition::localName (this=this@entry=0x0) at definition.cpp:1386
| No locals.
| #1 0x000000000058aed8 in NamespaceDef::addInnerCompound (this=0x15891e0,
d=0x0) at namespacedef.cpp:136
| No locals.
| #2 0x000000000041302d in buildScopeFromQualifiedName (name=..., level=1,
lang=SrcLangExt_Unknown, tagInfo=0x240fae0) at doxygen.cpp:1041
| idx = 0
| nsName = {m_data = 0x23f2ce0 "ACE_Equal_To< std::string >"}
| nd = <optimized out>
| innerScope = 0x0
| cd = <optimized out>
| i = 0
| prevScope = 0x15891e0
| fullScope = {m_data = 0x2f47b80 "ACE_Equal_To< std::string >"}
| p = <optimized out>
| l = 27
| #3 0x0000000000423f9d in addClassToContext (rootNav=0x16ca080) at
doxygen.cpp:1315
| i = 0
| className = {m_data = 0x23a6790 "ACE_Equal_To< std::string >"}
| tagName = {m_data = 0x3060570
"/home/helmut/tmp_ace/ace-6.2.7+dfsg/html/libace-doc/ACE.tag"}
| tArgList = 0x0
| namespaceName = {m_data = 0x0}
| refFileName = {m_data = 0x2db9f30 "a00198.html"}
| fullName = {m_data = 0x2f94a10 "ACE_Equal_To< std::string >"}
| qualifiedName = {m_data = 0x20ae050 "ACE_Equal_To< std::string >"}
| scName = {m_data = 0x0}
| cd = 0x0
| #4 0x0000000000424926 in buildClassList (rootNav=0x16ca080) at
doxygen.cpp:1392
| No locals.
| #5 0x00000000004248d6 in buildClassList (rootNav=0x1e5c2a0) at
doxygen.cpp:1394
| eli = {<QGListIterator> = {list = 0x311e7c0, curNode = 0x24104a0},
<No data fields>}
| #6 0x00000000004248d6 in buildClassList (rootNav=0x160c600) at
doxygen.cpp:1394
| eli = {<QGListIterator> = {list = 0x311cfd0, curNode = 0x1e975e0},
<No data fields>}
| #7 0x000000000043c1de in parseInput () at doxygen.cpp:10981
| pid = 47544528
| generateLatex = @0x2d578d0: 180
| generateMan = @0x160c600: false
| layoutFile = {<QIODevice> = {_vptr.QIODevice = 0xd4e9d0 <vtable for
QFile+16>, ioIndex = 0, ioMode = 256, ioSt = 5}, fn = {static null = {<No data
fields>}, d = 0x16042a0,
| static shared_null = 0x1516f00}, fh = 0x0, fd = 0, length = 0,
ext_f = false, d = 0x0, ungetchBuffer = {m_data = 0x0}}
| root = 0x160e770
| cacheSize = 0
| latexOutput = {m_data = 0x0}
| rtfOutput = {m_data = 0x0}
| rootNav = 0x160c600
| s = 0x0
| outputDirectory = @0x160e770: {m_data = 0x7f4103000000 <error: Cannot
access memory at address 0x7f4103000000>}
| xmlOutput = {m_data = 0x0}
| generateXml = @0x1614600: 144
| layoutFileName = @0x160e770: {m_data = 0x7f4103000000 <error: Cannot
access memory at address 0x7f4103000000>}
| exclPatterns = @0x160e770: {<QInternalList<char>> = {<QGList> =
{<QCollection> = {_vptr.QCollection = 0x7f4103000000, del_item = false},
firstNode = 0x0, lastNode = 0x0,
| curNode = 0x0, curIndex = 0, numNodes = 0, iterators =
0x1000000ffffffff}, <No data fields>}, dc = false}
| htmlOutput = {m_data = 0x15faed0
"/home/helmut/tmp_ace/ace-6.2.7+dfsg/./html/libace-doc/rmcast"}
| generateRtf = @0x15b01a0: 80
| manOutput = {m_data = 0x0}
| thisDir = {_vptr.QDir = 0x1613df0, dPath = {static null = {<No data
fields>}, d = 0x162ac70, static shared_null = 0x1516f00}, fList = 0x1, fiList =
0x0, nameFilt = {
| static null = {<No data fields>}, d = 0x15faed0, static
shared_null = 0x1516f00}, filtS = QDir::All, sortS = QDir::IgnoreCase, dirty =
1, allDirs = 0}
| docbookOutput = {m_data = 0x0}
| #8 0x0000000000409079 in main (argc=2, argv=0x7fff95352888) at main.cpp:37
Not sure what this tells us. The culprit seems to be in frame 2.
innerScope shouldn't be NULL. In the current loop iteration fullScope is
"ACE_Equal_To< std::string >".
I guess that Doxygen commit 6a60477b418e21dbadd3e62dc557a038e319581b is
related.
Even though I do have a traceback now, I did not succeed at producing a
small test case, because I have little clue about the inner workings of
generate_doxygen.pl. Can you try to come up with a smaller set of
smaller files that reproduce the issue? In particular eliminating the
need to run generate_doxygen.pl in favour of running doxygen on some
Doxyfile directly.
> After solving this bug, I would like to add ace to doxygen's auto
> > package tests in order to catch this kind of error more quickly. Can you
> > add a debian/rules target to ace that just builds the documentation
> > without actually creating the -doc package?
> >
> >
> I'm working on this but the magic added by debhelper is creating some
> trouble. I'll let you know when it's done.
It seems to me, that just adding a stable name for what currently is
override_dh_auto_build-indep would be enough.
Helmut
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]