Re: xml issues with oprofile-1.0.0-rc1

On 08/29/2014 12:37 PM, William Cohen wrote:
> On 08/28/2014 01:22 PM, Maynard Johnson wrote:
>> On 08/28/2014 11:11 AM, William Cohen wrote:
> 
>> Will,
>> Many thanks for all the testing you've done!  I will defer to Will Deacon on the problem with running operf/ocount on cortex-a9, but I have answers for the XML-related test failures for you.  See below.
>>>
>>> -Will
>>>
>>> (1)
>>> Running ./oprofile-operf/oprofile-operf-run.exp ...
>>> FAIL:     XML opreport output with callgraph option=1 is invalid
>>> warning: failed to load external entity "/share/doc/oprofile/opreport.xsd"
>>> Schemas parser error : Failed to locate the main schema resource at '//share/doc
>>> /oprofile/opreport.xsd'.
>> Coincidentally, I have recently seen this error reported to me by one of my IBM colleagues when testing the RC1 on ubuntu.  Turned out that, for some reason, the deb package had opreport.xsd installed as a tar file (opreport.xsd.gz) instead of plain text.  Probably something like that happening here, too -- or simply missing from the install.
> 
> There does seems to be an opreport.xsd installed by the rpm, but it looks like something is looking in the wrong place, /share/doc/oprofile.xsd:
> 
> $ rpm -qs oprofile|grep xsd
> normal        /usr/share/doc/oprofile/ophelp.xsd
> normal        /usr/share/doc/oprofile/opreport.xsd
> 
> The wierd thing is that on one f20 x86_64 machine it is working, but on another it doesn't.

I did some additional poking around and found why it was working on one machine but not the other.

The testsuite/lib/verify.exp has the following snippet determine where to look for the opreport.xsd in validate_xml_report:

	set binpath [lindex [local_exec "which operf" "" "" 10] 1]
	set idx [string last "/bin" $binpath ]
	set op_install_dir [string range $binpath 0 $idx ]
	append schema_file $op_install_dir "/share/doc/oprofile/opreport.xsd"
	set opreport_result [local_exec "opreport --debug-info --symbols $cg_option --long-filenames --xml -o out.xml" "" "" 100 ]
	set xmllint_result [local_exec "xmllint --noout --schema $schema_file out.xml"  "" "" 10 ]

the oprofile rpm installs operf in /usr/bin/operf.  However fedora has the following symbollic link so /usr/bin/operf also is visible as /bin/operf:

$ ls -ld /bin
lrwxrwxrwx. 1 root root 7 Apr 17 14:23 /bin -> usr/bin

On the machine that works the $PATH is 

# echo $PATH
/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin


On the machines with problems the $PATH is:

# echo $PATH
/usr/lib64/ccache:/sbin:/bin:/usr/sbin:/usr/bin

For some reason logging directly in as root gave the first $PATH that worked, while "sudo bash" gave resulted in the second $PATH.
Thus, for the second $PATH the test will find /bin/operf before /usr/bin/operf.  This messes up generation of schema_file path.

I guess I will just need to use "su" rather than using "sudo bash" or "su -"

-Will

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/