Project

General

Profile

Bug #1681

maus095 using switch_unpacker

Added by Kyberd, Paul over 8 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Karadzhov, Yordan
Category:
Build System
Target version:
MAUS-v0.9.6
Start date:
14 May 2015
Due date:
% Done:

100%

Estimated time:
Workflow:
New Issue

Description

maus095 installed and built correctly.
on running switch_unpacker StepI - the tests failed with the following output

oing to search for run 05466 data files in /home/paul/research/maus095/src/input/InputCppDAQData
Trying to add file 05466.001 from /home/paul/research/maus095/src/input/InputCppDAQData
File 05466.001 is added
.WARNING in MDequipMap::MDequipMap() : Trying to create a multiple instances of a static singleton class
WARNING : The first event is not a START_OF_RUN. Spill count and Event count not accurate.
ERROR in in MDprocessManager::ProcessEvent :
Sub Event Mismatch (nLdcs: 3!=1).
  • Unpacking exception in void InputCppDAQData::getCurEvent(MAUS::Data *data) :
    DAQ Event skipped!
ERROR in in MDprocessManager::ProcessEvent :
Sub Event Mismatch (nLdcs: 3!=1).
  • Unpacking exception in void InputCppDAQData::getCurEvent(MAUS::Data *data) :
    DAQ Event skipped!
ERROR in in MDprocessManager::ProcessEvent :
Sub Event Mismatch (nLdcs: 3!=1).
  • Unpacking exception in void InputCppDAQData::getCurEvent(MAUS::Data *data) :
    DAQ Event skipped!

Traceback (most recent call last):
File "/home/paul/research/maus095/src/common_py/ErrorHandler.py", line 159, in HandleCppException
raise CppError(error_message)
ErrorHandler.CppError: Failed to read next event at InputCppDAQData::_emit_cpp()
12
FWARNING in MDequipMap::MDequipMap() : Trying to create a multiple instances of a static singleton class
WARNING : The first event is not a START_OF_RUN. Spill count and Event count not accurate.
. ======================================================================
FAIL: test_multi (main.InputCppDAQOfflineDataTestCase)
Test reading the whole file
----------------------------------------------------------------------
Traceback (most recent call last):
File "src/input/InputCppDAQOfflineData/test_InputCppDAQOfflineData.py", line 108, in test_multi
self._checksum)
AssertionError: 'f226ea9b823996f653a73fd9e969b2f2' != 'f699f0d81aee1f64a2f1cec7968b9289'

----------------------------------------------------------------------
Ran 3 tests in 4.817s

FAILED (failures=1)

FATAL: Unpacker test failed

#1

Updated by Dobbs, Adam over 8 years ago

  • Category set to Build System
  • Assignee set to Dobbs, Adam

Confirmed. Odd, it was fine. Investigating...

#2

Updated by Dobbs, Adam over 8 years ago

Yordan, has anything changed in the unpacker library source recently that could have caused this?

#3

Updated by Dobbs, Adam over 8 years ago

Just checked, the switch_unpacker script seems to be behaving as expected, the third party unpacking library is rebuilt, the soft link is correctly set to the StepI unpacker library, and MAUS is being cleaned and rebuilt. The issue arises when the InputCppDAQOfflineData test is run at the end of the script, throwing an unpacker error.

#4

Updated by Dobbs, Adam over 8 years ago

It might be shutting the stable door after the horse has bolted, but I have just made a Jenkins job to explicitly test the StepI unpacker: http://test.mice.rl.ac.uk/view/Trunk/job/MAUS_StepI_Unpacker/ Expected to fail until we fix this.

#5

Updated by Dobbs, Adam over 8 years ago

  • Assignee changed from Dobbs, Adam to Karadzhov, Yordan
#6

Updated by Rajaram, Durga over 8 years ago

Well, the unpacking_mice_2 md5 and tarbarll size have certainly changed since 0.9.4 -- looks like on May 12.
Yordan - can we freeze an unpacker after releasing it and update with a new version number?
Or when we make a MAUS release, we'll have to stick the tarball & md5 on micemine or a heplnm node so that
the released version doesn't change on the fly.

#7

Updated by Dobbs, Adam over 8 years ago

OK, it was the updates to the unpacker. I pulled down the 0.9.4 version of the unpacker from micewww, and that passes the tests for both StepI and StepIV.

I am uncomfortable with leaving this pulling from Geneva, releases should be fixed as far as possible. I have updated the trunk to now point at a location on micewww for the unpacker tarball. Yordan, in future please send me any updates you have for the unpacker and I will then put them up on the server.

#8

Updated by Karadzhov, Yordan over 8 years ago

Hi all,
Sorry for the delay of my answer, but you are getting me in the middle of the swiss bank holidays and I am deep in the Alps. I will try to address this problem in Monday. I can confirm that I changed the unpacking version for MICE and I don't think that the problem is the unpacking itself. It is more probably in the test. The new unpack has a more sophisticated protection against corrupted data and as you can see in the error message posted above, it throws exception in the case of a missing data from some of the LDCs.

#9

Updated by Dobbs, Adam over 8 years ago

Thanks for the update Yordan. If you can fix the test, then I will update the unpacker on micewww back to the latest version. I am however going to keep the default unpacker tarball located there, as it is important we try to keep releases fixed.

#10

Updated by Dobbs, Adam over 8 years ago

  • Target version set to MAUS-v0.9.6

Resolved in at least MAUS 0.9.6, closing the issue.

#11

Updated by Dobbs, Adam over 8 years ago

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

Also available in: Atom PDF