Bug #1146
Weirdness in OutputCppRoot
0%
Description
Consider the following from test_OutputCppRoot.py:
def test_save_run_header(self):
"""
test_OutputCppRoot: Try saving a run header
"""
self.assertTrue(self.sub_function(
json.dumps(self.test_run_header)
))
self.test_run_header["run_number"] = 2
for i in range(1000): # pylint:disable=W0612
self.assertTrue(self.sub_function(
json.dumps(self.test_run_header)
))
self.test_run_header["run_number"] = 3
self.sub_function_2(json.dumps(self.test_run_header))
#self._save_event(json.dumps(self.test_run_header)) SEGMENTATION FAULT
#self.output.save(json.dumps(self.test_run_header)) SEGMENTATION FAULT
self.output.death()
self.__check_run_header(1, 1002, 0)
self.__check_run_header(2, 1002, 1000)
Files
Updated by Rogers, Chris almost 11 years ago
The problem is that the two lines marked SEGMENTATION FAULT, when uncommented, produce a seg. The thing that distinguishes them is that the function calls to save_event are nested in one or no levels of function calls. The other function calls are nested in two levels of function calls.
Updated by Rogers, Chris almost 11 years ago
Ping Alex - thought you might like to know this exists - it's a weird one (i.e. fun). I can take it unless you want to have a go.
Updated by Rogers, Chris almost 11 years ago
Hum, test server is giving me a stack trace... let me dig
Updated by Rogers, Chris almost 11 years ago
Looks like stack trace is unrelated - raised as #1149
Updated by Richards, Alexander almost 11 years ago
Hi Chris,
I don't have this code in my version of " test_OutputCppRoot.py " from the control room branch. Which branch is it in?
Cheers
Alex
Updated by Rogers, Chris almost 11 years ago
I just merged it into the trunk (I sent you email). But it was in my rogers branch, sorry I should have mentioned it.
Updated by Richards, Alexander almost 11 years ago
Is there some special setup I'm missing? I get the following when running the test.
[arichard@heppc242 OutputCppRoot]$ python -m unittest test_OutputCppRoot
Traceback (most recent call last):
File "/home/hep/arichard/Maus/merge/third_party/install/lib/python2.7/runpy.py", line 162, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/home/hep/arichard/Maus/merge/third_party/install/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
File "/home/hep/arichard/Maus/merge/third_party/install/lib/python2.7/unittest/__main__.py", line 12, in <module>
main(module=None)
File "/home/hep/arichard/Maus/merge/third_party/install/lib/python2.7/unittest/main.py", line 94, in __init__
self.parseArgs(argv)
File "/home/hep/arichard/Maus/merge/third_party/install/lib/python2.7/unittest/main.py", line 149, in parseArgs
self.createTests()
File "/home/hep/arichard/Maus/merge/third_party/install/lib/python2.7/unittest/main.py", line 158, in createTests
self.module)
File "/home/hep/arichard/Maus/merge/third_party/install/lib/python2.7/unittest/loader.py", line 128, in loadTestsFromNames
suites = [self.loadTestsFromName(name, module) for name in names]
File "/home/hep/arichard/Maus/merge/third_party/install/lib/python2.7/unittest/loader.py", line 91, in loadTestsFromName
module = __import__('.'.join(parts_copy))
File "test_OutputCppRoot.py", line 31, in <module>
import maus_cpp.globals
ImportError: No module named maus_cpp.globals
Updated by Rogers, Chris almost 11 years ago
python src/output/OutputCppRoot/test_OutputCppRoot.py
Works for me... obvuiously
source env.shfirst
Updated by Rogers, Chris almost 11 years ago
Redo scons? There should be C/Python library build/maus_cpp/globals.so and $MAUS_ROOT_DIR/build should be in your $PYTHONPATH
Updated by Rogers, Chris almost 11 years ago
Scratch that, read the issue properly... did you make progress on it? Can I reassign issue to you i.e. did you get the branch to compile etc
Updated by Richards, Alexander almost 11 years ago
Hi Chris.
I see no maus_cpp/globals.so below $MAUS_ROOT_DIR/build
This is with a fully updated "merge" (dev branch) and with the env sourced and scons run with no problems (that I noted)
Cheers
Alex
Updated by Rogers, Chris almost 11 years ago
Strange, I can see it here (trunk test server build):
http://test.mice.rl.ac.uk/view/Shared_builds/job/MAUS_per_commit/ws/
Updated by Richards, Alexander almost 11 years ago
Maybe the bzr branch info is wrong, I must admit to being alarmed that it mentions related branches which aren't the branch that I'm using but location seems right.
[arichard@heppc242 OutputCppRoot]$ bzr info
Standalone tree (format: 2a)
Location:
branch root: /home/hep/arichard/Maus/merge
Related branches:
push branch: bzr+ssh://bazaar.launchpad.net/+branch/maus/merge/
parent branch: bzr+ssh://bazaar.launchpad.net/+branch/maus/merge/
submit branch: bzr+ssh://bazaar.launchpad.net/~a-richards/maus/API/
Updated by Richards, Alexander almost 11 years ago
What revision do you see?
[arichard@heppc242 OutputCppRoot]$ bzr update Tree is up to date at revision 841 of branch /home/hep/arichard/Maus/merge
Updated by Rogers, Chris almost 11 years ago
info result: bzr revision-info -d /var/lib/jenkins/jobs/MAUS_per_commit/workspace returned 0. Command output: "842 matt@matts-laptop-20121112142810-t6vzobxoqqbxog34
is the test server build that has the globals.so - let me check I can reproduce the segmentation fault...
Updated by Rogers, Chris almost 11 years ago
- File valgrind.log valgrind.log added
Indeed, doing
valgrind python src/output/OutputCppRoot/test_OutputCppRoot.py >& valgrind.log
leads to the attached valgrind.log