Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#236 opreport XML: binary-level count field issues

None
open-fixed
None
5
2014-06-09
2013-01-30
Maynard Johnson
No

There are a couple of issues relating to the 'count' element of the 'binary' element. Below is the schema definition for 'binary':

<xs:element name="binary">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="1" maxOccurs="1" ref="count"/>
<xs:element minOccurs="0" maxOccurs="unbounded" ref="symbol"/>
<!-- When the separate=lib option is used an binary
can contain a list of library Modules. -->
<xs:element minOccurs="0" maxOccurs="unbounded" ref="module"/>
</xs:sequence>
<xs:attribute name="name" type="xs:string" use="required"/>
</xs:complexType>
</xs:element>
-------------------------------------------------------------------

There have been questions from users whether the 'count' element associated with the 'binary' element is supposed to represent a total count across all modules for the executable. This should be documented in the opreport.xsd.

Another issue involves intermittent cases where XML output contains a binary element that looks something like the following:

<binary name="/memcpyt">
<module name="/lib64/libc-2.12.so">
<count>
44807</count>
<symbol idref="6">
<count>
44807</count>
</symbol>
</module>
<module name="/home/mpj/test-stuff/memcpyt">
<count>
23169</count>
<symbol idref="7">
<count>
20436</count>
</symbol>
<symbol idref="8">
<count>
2733</count>
</symbol>
</module>
</binary>
----------------

In the case above, the application that was profiled was /home/mpj/test-stuff/memcpyt, but note the 'name' attribute of the 'binary' element -- "/memcpyt" -- is incomplete. Also note that there is no 'count' element associated with the 'binary' element, even though this schema requires a 'count' element. Further, note that there is a module entry for the /home/mpj/test-stuff/memcpyt with a 'count' element, so at least there is no data lost. However, the XML generated fails to pass validation (see http://www.freeformatter.com/xml-validator-xsd.html\). I've only seen this case once, and it was after collecting a profile with operf. Is it a timing issue with PERF_RECORD_MMAP and PERF_RECORD_COMM?

Discussion

  • A patch for this bug was posted to the oprofile-list today.

     
    • status: open --> open-fixed
    • assigned_to: Maynard Johnson
    • Group: -->
     
  • The patch was pushed upstream on May 29. Bug fixed.