[lttng-dev] Running lttng-tools tests?

[Thibault, Daniel]

   I tried deploying the tarball to another directory and building.  The tests refuse to run ("Could not execute (unit/test_kernel_data): open3: exec of unit/test_kernmel_data failed at /usr/share/perl/5.14/TAP/Parser/Iterator/Process.pm line 168") until after the make step (naturally).  This time I got:

unit/test_kernel_data .............. ok
unit/test_session .................. ok
unit/test_uri ...................... Dubious, test returned 1 (wstat > 256, 0x100)
Failed 1/11 subtests
unit/test_ust_data ................. ok
unit/test_utils_parse_size_suffix .. ok

Test Summary Report
-------------------
unit/test_uri                    (Wstat: 256 Tests: 11 Failed: 1)
  Failed test:  4
  Non-zero exit status: 1
Files=5, Tests=55,  4 wallclock secs ( 0.13 usr  0.08 sys +  1.34 cusr  1.02 csys =  2.57 CPU)
Result: FAIL

   Now I get exactly the same report in the original /usr/src/... folder if I run 'sudo ./run.sh unit_tests' instead of 'sudo ./run.sh unit_tests'.  The problem is clearly one of file ownership (a lot of the /usr/src/... files are root-owned because of the way they were installed).

~~~~~~~~~~
   I was looking into the babeltrace tests as well (cd babeltrace/tests/, ./runall.sh) and I was surprised that every single "succeed" test failed.  Investigation revealed that the babeltrace/converter/babeltrace executable was responsible: it fails with "/usr/bin/ld: fatal error: /usr/src/babeltrace-1.1.0/converter/.libs/26622-lt-babeltrace: open: Permission denied" "collect2: ld a retourné 1 code d'état d'exécutionn".  Surprisingly, the babeltrace/converter/babeltrace executable is *different* from the /usr/local/bin/babeltrace executable (according to diff).  So are the babeltrace-log executables.  The timestamps are four seconds apart.

   The install log shows nothing strange: "libtool: install: /usr/bin/install -c .libs/babeltrace /usr/local/bin/babeltrace".  /usr/bin/install is supposed to do a plain copy, no?

   Changing runall.sh so it runs the installed /usr/local/bin/babeltrace yields successful tests except for the succeed3 trace:

$ babeltrace /usr/src/babeltrace-1.1.0/tests/ctf-traces/succeed/succeed3
[error] at line 9: token ""?\x20\o040?"": syntax error, unexpected ERROR

[error] Error creating AST
[warning] Unable to open trace metadata for path "/usr/src/babeltrace-1.1.0/tests/ctf-traces/succeed/succeed3".
[warning] [Context] Cannot open_trace of format ctf at path /usr/src/babeltrace-1.1.0/tests/ctf-traces/succeed/succeed3.
[warning] [Context] cannot open trace "/usr/src/babeltrace-1.1.0/tests/ctf-traces/succeed/succeed3" from /usr/src/babeltrace-1.1.0/tests/ctf-traces/succeed/succeed3 for reading.
[error] Cannot open any trace for reading.

[error] opening trace "/usr/src/babeltrace-1.1.0/tests/ctf-traces/succeed/succeed3" for reading.

[error] none of the specified trace paths could be opened.

   Here also, ownership is responsible: running 'sudo ./runall.sh' (on the original runall.sh) yields the same successes (and the same succeed3 trace failure).

   So at this point I have three remaining questions:

1) Why does unit/test_uri fail one of its 11 sub-tests?
2) Why does babeltrace fail when reading the succeed3 ctf trace?
3) Why on Earth are the babeltrace executables tampered with when installed?

Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection & Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber Security (MCCS)
R & D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence R&D Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ <http://www.travelgis.com/map.asp?addr=918V%20QSDJ>
Gouvernement du Canada | Government of Canada
<http://www.valcartier.drdc-rddc.gc.ca/>