Project

General

Profile

Bug #1476

MAUS merge branch failing test_run_test_cpp_unit on my machine

Added by Pidcott, Celeste over 7 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Testing
Target version:
Start date:
23 May 2014
Due date:
% Done:

100%

Estimated time:
Workflow:
New Issue

Description

I am running SL6.5, install.log is attached


Files

install.log (8.46 MB) install.log Pidcott, Celeste, 23 May 2014 11:20
test_cpp_unit.log (25.5 KB) test_cpp_unit.log log from running test_cpp_unit Rajaram, Durga, 31 May 2014 02:47
#1

Updated by Pidcott, Celeste over 7 years ago

  • Assignee set to Rajaram, Durga
#2

Updated by Greis, Jan over 7 years ago

Just for completeness, the same issue seems to occur for the release branch.

#3

Updated by Dobbs, Adam over 7 years ago

I also see the

TrackerDataManagtests/cpp_unit/Recon/Global/PIDVarBTest.cc:45: Failure

failure.

#4

Updated by Rogers, Chris over 7 years ago

Note that I have donated my desktop to act as an SL64 test server for the time being as rogers_sl64. It is building third party libraries, so far it has got through geant4 build and into G4BL...

I don't guarantee to leave this machine on, but I don't expect to take it offline in the near future.

#5

Updated by Rajaram, Durga over 7 years ago

Hm the SL64 third party build on the test server failed at the same point -- test_cpp_unit

On my SLF 6.3, 64-bit 2.6.32-358.11.1.el6.x86_64, gcc 4.4.6, I see the same.

Tailed output of

tests/cpp_unit/test_cpp_unit

....
Failed to evaluate expression "1." 
Error parsing MiceModule Test.dat property Dimensions. Error was reported as 'Could not convert 1. to a double'
MiceModule::propertyHep3Vector
/home/durga/trunk-dev/build/libMausCpp.so(_ZNK10MiceModule18propertyHep3VectorESs+0x726) [0x7f774c9122bc]
/home/durga/trunk-dev/build/libMausCpp.so(_ZNK10MiceModule10dimensionsEv+0x150) [0x7f774c90b984]
/home/durga/trunk-dev/build/libMausCpp.so(_ZN4MAUS26MAUSPrimaryGeneratorAction15isInWorldVolumeEddd+0x99) [0x7f774cf8dce3]
/home/durga/trunk-dev/build/libMausCpp.so(_ZN4MAUS26MAUSPrimaryGeneratorAction17GeneratePrimariesEP7G4Event+0x72d) [0x7f774cf8d435]
/home/durga/trunk-dev/third_party/install/lib64/libG4run.so(_ZN12G4RunManager13GenerateEventEi+0x105) [0x7f7750e85215]
/home/durga/trunk-dev/third_party/install/lib64/libG4run.so(_ZN12G4RunManager15ProcessOneEventEi+0x14) [0x7f7750e84044]
/home/durga/trunk-dev/third_party/install/lib64/libG4run.so(_ZN12G4RunManager11DoEventLoopEiPKci+0x35) [0x7f7750e83e65]
/home/durga/trunk-dev/third_party/install/lib64/libG4run.so(_ZN12G4RunManager6BeamOnEiPKci+0x7c) [0x7f7750e84a6c]
/home/durga/trunk-dev/build/libMausCpp.so(_ZN4MAUS17MAUSGeant4Manager16RunManyParticlesEN4Json5ValueE+0x327) [0x7f774cf92483]
/home/durga/trunk-dev/build/libMausCpp.so(_ZN4MAUS21PolynomialOpticsModel5BuildEv+0x621) [0x7f774cfeb085]
tests/cpp_unit/test_cpp_unit() [0x8d45e9]
/home/durga/trunk-dev/third_party/install/lib/libgtest.so.0(_ZN7testing4Test3RunEv+0xaa) [0x7f774d914eea]
/home/durga/trunk-dev/third_party/install/lib/libgtest.so.0(_ZN7testing8internal12TestInfoImpl3RunEv+0x108) [0x7f774d914ff8]
/home/durga/trunk-dev/third_party/install/lib/libgtest.so.0(_ZN7testing8TestCase3RunEv+0xb5) [0x7f774d9150b5]
/home/durga/trunk-dev/third_party/install/lib/libgtest.so.0(_ZN7testing8internal12UnitTestImpl11RunAllTestsEv+0x2cf) [0x7f774d916daf]
tests/cpp_unit/test_cpp_unit() [0x8f44c3]
/lib64/libc.so.6(__libc_start_main+0xfd) [0x387a41ed1d]
tests/cpp_unit/test_cpp_unit() [0x5e9dc9]

#6

Updated by Rajaram, Durga over 7 years ago

The error message

Failed to evaluate expression "1."
is coming from MAUSEvaluator::evaluate:82 which is throwing an exception because the return from the python evaluator is NULL.

The evaluator is getting called from various places in the parseString(...) methods in src/legacy/Config/ModuleTextFileIO which in turn is getting called from MiceModule which is throwing the

Error parsing MiceModule Test.dat property Dimensions. Error was reported as 'Could not convert 1. to a double'

But...if I print from within the python evaluator it seems to be doing ok.

And....common_cpp/Utils/MAUSEvaluator has not changed since Jan, r693, release 0.7.6
Neither have MiceModule or ModuleTextFileIO
and common_py/evaluator.py hasn't changed in over 2 years

#7

Updated by Rajaram, Durga over 7 years ago

Tracing back, it looks like this started at r711
r710 passes cpp tests OK.

The only thing I see in r711 that might impact is the change to module_builder.py as part of the api changes.

Chris -- do you see anything obvious?

#8

Updated by Rogers, Chris over 7 years ago

Working on it...

#9

Updated by Rogers, Chris over 7 years ago

  • Category set to Testing
  • Assignee changed from Rajaram, Durga to Rogers, Chris
  • Target version set to Future MAUS release

In test

http://test.mice.rl.ac.uk/job/MAUS_rogers_sl64/1

I rewrote the function that calls the python exception handler - this was previously done in a somewhat ungraceful manner (who wrote that junk - oh me)

#10

Updated by Dobbs, Adam over 7 years ago

Aside: Just checked it on my 64bit Ubuntu laptop, and it built and completed the tests without issue.

#11

Updated by Rajaram, Durga over 7 years ago

Hm it's still failing on my SLF 6.3 at the same place -- fresh install of trunk r733 -- test_cpp_unit.log attached test_cpp_unit.log

[durga@fermice1 devel]$ bzr revno
733
[durga@fermice1 devel]$ bzr status
unknown:
  install.log
  log
  src/map/MapPyBeamlineSimulation/G4bl/maps/TypeIBend_6InchGap_tapered.map
  third_party/install/lib64/
[durga@fermice1 devel]$ uname -a
Linux fermice1.fnal.gov 2.6.32-358.11.1.el6.x86_64 #1 SMP Tue Jun 11 17:23:30 CDT 2013 x86_64 x86_64 x86_64 GNU/Linux
[durga@fermice1 devel]$ cat /etc/issue
Scientific Linux Fermi release 6.3 (Ramsey)
Kernel \r on an \m

[durga@fermice1 devel]$ gcc --version
gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[durga@fermice1 devel]$

#12

Updated by Rajaram, Durga over 7 years ago

Is rogers_sl64 a SL 6.4 box? Or does the 64 refer to 64-bit?
The kernel seems the same.

Started up a rebuild of the MAUS_per_commit_third_party_sl64 that had failed earlier

#13

Updated by Rajaram, Durga over 7 years ago

The third party build on rogers_sl64 succeeded.
But for some reason still failing on my SLF 6.3

What version of SL does the grid run on?

#14

Updated by Rogers, Chris over 7 years ago

I think it is SL6.4. I realised that when I ran it on SL6 it was failing at a different point - which is why I attacked the CppErrorHandler. I wonder if this is a test ordering issue?

#15

Updated by Rogers, Chris over 7 years ago

Correction to previous comment:

> $ uname -a
Linux localhost.localdomain 2.6.32-431.17.1.el6.x86_64 #1 SMP Wed May 7 14:14:17 CDT 2014 x86_64 x86_64 x86_64 GNU/Linux
> $ cat /etc/redhat-release 
Scientific Linux release 6.5 (Carbon)

Hum, I could try to install SLF63 as a VM?

#16

Updated by Rajaram, Durga over 7 years ago

Hm I'll see if I can upgrade to SL 6.4 and check when I return to the lab Sunday.
Are all the MLCR machines going to 6.4? Or is it 6.5?
I'm ok with saying SL5, and >= SL 6.4 are supported but I wonder if the error at lower SL6 versions points to something nasty lurking underneath

#17

Updated by Rogers, Chris over 7 years ago

Ah, my fault as usual. Looks like it was a test ordering issue. The PyObjectWrapper delete_json_cpp test was leaving a Python exception set (when it failed to delete a PyObject of the wrong type) and this was causing a failure in other tests that use python function calls. In the example above, evaluation of expressions in MiceModules is done by a call to the python parser, and this was failing. So:

  • I fixed PyObjectWrapper::delete_json_cpp so that it clears the python exception before quitting
  • I fixed the PyObjectWrapper tests so that they check for stray PyErrors
  • I could also add a test job to the trunk that tries shuffling the cpp unit tests
#18

Updated by Rogers, Chris over 7 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100

Also available in: Atom PDF