Support #753
The code passes the tests on my laptop byt fails on the test serer
100%
Description
The code in my branch fails to pass the tests on the test server getting
the message:
called after throwing an instance of 'Squeal'
what(): Failed to parse Json configuration. Json reports
- Line 1, Column 1
Syntax error: value, object or array expected.
at JsonWrapper::StringToJson()
see also: http://test.mice.rl.ac.uk/job/MAUS_karadzkov/29/console
This is strange because on my laptop, when I run
./run_tests.bash
this test is passed without any problems.
The test which fails is
http://test.mice.rl.ac.uk/job/MAUS_karadzkov/ws/src/map/MapCppTOFDigits/test_MapCppTOFDigits.py/*view*/
see also
http://test.mice.rl.ac.uk/job/MAUS_karadzkov/ws/src/map/MapCppTOFDigits/MapCppTOFDigits.cc/*view*/
Updated by Rogers, Chris over 11 years ago
- Category set to common_cpp
- Assignee set to Rogers, Chris
- Target version set to Future MAUS release
Looks weird. Works on my PC also.
Updated by Rogers, Chris over 11 years ago
I think this is a bug in gcc/scons/swig ... there is a symbol for Squeal in _MapCppTofDigitization.so and another one in libMausCpp.so. gcc fails to recognise that they are the same object. I'll see if I can figure out a fix/workaround.
Updated by Rogers, Chris over 11 years ago
It's weird, the code that is in e.g. http://test.mice.rl.ac.uk/job/MAUS_karadzkov/ws/src/map/MapCppTOFDigits/MapCppTOFDigits.cc/*view*/ doesn't seem to reflect the code that I see when actually browsing the test server. Tried kicking off another build to understand what is going on.
Deja Vu? I'm sure this happened before...
Updated by Rogers, Chris over 11 years ago
I'm trying a workaround where I call the error handler - because error handler sits in libMausCpp.so, it should see the correct symbol from this library. Also catch std::exception - Squeal inherits from std::exception, so this should catch anything. I want to use the error handler in any case (allows to change error handling ability at run time for example, or if we decide to do it "another way" then we can).
By the way, I just had a flick through your tests. Much better and more comprehensive. It's obviously worked as we caught a subtle bug that otherwise could have been missed.
Updated by Rogers, Chris over 11 years ago
Okay, that worked. If you look at
http://test.mice.rl.ac.uk/job/MAUS_karadzhov_2/5/console
test_empty (test_MapCppTOFDigits.MapCppTOFDigitsTestCase) ... ok test_init (test_MapCppTOFDigits.MapCppTOFDigitsTestCase) ... ok test_no_data (test_MapCppTOFDigits.MapCppTOFDigitsTestCase) ... ok test_process (test_MapCppTOFDigits.MapCppTOFDigitsTestCase) ... ok
Note that test scripts go on to fail in later stuff (MapCppTOFSlabHitsTestCase).
test_empty (test_MapCppTOFSlabHits.MapCppTOFSlabHitsTestCase) ... terminate called after throwing an instance of 'Squeal' what(): Failed to parse Json configuration. Json reports * Line 1, Column 1 Syntax error: value, object or array expected. at JsonWrapper::StringToJson() ./run_tests.bash: line 29: 32729 Aborted nosetests --with-coverage -v build
It's a sort of sinister problem, perhaps related to slightly older gcc version 4.1 on the test server. You can see what I changed at:
http://test.mice.rl.ac.uk/job/MAUS_karadzhov_2/ws/src/map/MapCppTOFDigits/MapCppTOFDigits.cc/*view*/
General comment about the way you do exceptions - the usual thing to do would be if a function call fails, let the C++ exception mechanism walk up the call stack. Slight problem, specific to C++ is that any memory allocated needs to be deleted on the way.
Looking at e.g.
bool TOFCalibrationMap::LoadT0File(std::string t0File) ... SNIP try { while (!stream.eof()) { stream >> key >> p0 >> reff; int n = FindTOFChannelKey(key); _t0[n] = p0; _reff[n] = reff; // std::cout << key << " pos:" << n << " t0:" << p0 << " reff:" << reff << std::endl; } } catch(Squeal e) { Squeak::mout(Squeak::error) << "Error in TOFCalibrationMap::LoadT0File : Error during loading. " << std::endl << e.GetMessage() << std::endl; return false; } ... SNIP
well normally I would just let the exception mechanism walk up the call stack rather than explicitly catching and throwing. Maybe you wanted to make the error message here? Also really such an error message would be better on the exception I think (if we run this in parallel stuff going to the Squeak::error potentially ends up going to /dev/null - haven't really figured that out yet).
Anyway, let me know if it works for you and I will close the issue...
Updated by Karadzhov, Yordan over 11 years ago
failure on the test server again. This time I have:
./run_tests.bash: line 29: nosetests: command not found
Build step 'Execute shell' marked build as failure
Updated by Rogers, Chris over 11 years ago
- Status changed from Open to Closed
- % Done changed from 0 to 100
Updated by Rogers, Chris over 11 years ago
Looks like probably a download error. The third party stuff is not good for checking failure to install code (so it keeps on going even if an installation failed). I'll try to redo the build and check that it tests.
Nb: it builds and tests okay on my machine except for a cpplint error on line 105 of MapCppTOFSlabHits and a whole bunch of style errors in test_MapBlah.py stuff. I can fix the style errors if you like...
Updated by Karadzhov, Yordan over 11 years ago
Looks OK now. I see, that I have A LOT OF python style errors. I am not familiar with the python style rules and will need some time to fix this. If you can fix the style quickly, this will be great.
Updated by Karadzhov, Yordan over 11 years ago
The same problem again. On My laptop everything is OK but on the test server my branch can't pass some of the integration tests.
http://test.mice.rl.ac.uk/job/MAUS_karadzkov/46/console
Updated by Rogers, Chris over 11 years ago
Try running tests/integration/integration_tests.bash
Looks like a genuine problem - looking at e.g.
http://test.mice.rl.ac.uk/job/MAUS_karadzkov/ws/tmp/
There are a whole load of missing files that never got generated (e.g. in the case of simulate_mice.py, we try running the simulation binary and check that it makes a beam - at the moment there's not even a simulation output file, so something went wrong here). Worrying/annoying that even the log files are empty...
Updated by Rogers, Chris over 11 years ago
nb: the reason we changed ROOT version was for latest ubuntu people - ROOT 5.28 doesnt build on new ubuntu distributions (because of ROOT badness and Ubuntu strictness)