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

I also see the

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

failure.

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.

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]

The error message

Failed to evaluate expression "1."

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

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?

Working on it...

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

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

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?

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?

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?

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

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