Support #497
Memory allocation failed in MDdateFile
100%
Description
hi there
I've tried my best to faithfully follow the instructions in the G4MICE
install from source guide. I now have a new install of G4MICE which appears
to have compiled successfully.
However, when I try to run either TofMonitor or TofTree I get an error:
$> ./TofMonitor cards.in ./02880.000
RooFit v2.50 -- Developed by Wouter Verkerke and David Kirkby
Copyright (C) 2000-2008 NIKHEF, University of California &
Stanford University
All rights reserved, please read
http://roofit.sourceforge.net/license.txt
=========== TofRec ============
CalibrationMode 0
Trigger from - TOF1
MakeSpacePiontCut = 500 ps
FindTriggerPixelCut = 500 ps
===============================
Warning in <TROOT::Append>: Replacing existing TH1: hxy (Potential memory
leak).
Warning in <TROOT::Append>: Replacing existing TH1: hStationMonitorPlane0
(Potential memory leak).
Warning in <TROOT::Append>: Replacing existing TH1: hStationMonitorPlane1
(Potential memory leak).
Warning in <TROOT::Append>: Replacing existing TH1: hStationMonitor_x
(Potential memory leak).
Warning in <TROOT::Append>: Replacing existing TH1: hStationMonitor_y
(Potential memory leak).
TofMonitor: Input file ./02880.000, event # 0
RunNum = 2880, 02880.
Memory allocation failed in MDdateFile::GetNextEvent()
using default cards:
numEvts 100000000
MiceModel MICEStage2/Stage2.dat
TofTriggerStation 1
Therefore using the default cabling and calib files.
I get the identical error in TofTree.
As I said this is a completely new install. Is there an issue with the
unpacking libraries? I've taken the versions given in the wget commands in
the guide and I've tried on two different boxes. I'm running on SL5, 64 bit.
Updated by Rogers, Chris over 12 years ago
I should say the issue was reported by email by David Forrest
Updated by Tunnell, Christopher over 12 years ago
From email I wrote:
64-bit unpacker won't work in G4MICE.
Continue at your own risk, but there is a version of the unpacker for MAUS at:
https://code.launchpad.net/~maus-dev/unpacking/maus
where we've made a few hacks to make it work with 64-bit. This should link to it:
http://micewww.pp.rl.ac.uk/projects/maus/repository/raw/third_party/source/unpacking-maus.tar.gz
but requires SCons for the MAUS-specific hacked unpacker. If you try to swap that in, it should work.... but who knows. Otherwise, Yordan is now in charge of the unpacker.
Updated by Tunnell, Christopher over 12 years ago
You may be able to force 32-bit compilation too.... not sure how. The "official" stance is that the unpacker doesn't support 64-bit. I've suggested some tricks to help... 'unofficially'.
Updated by Forrest, David over 12 years ago
Thanks Chris.
Swopping in the scons'd MAUS unpacker allowed the program to start however it quickly picked up an error (regular output followed by the error):
MICEEvent contains 0001 tracks, 0002 space points, 0005 slab hits, 0010 digits, 0048 VME TDC hits, and 0168 VME FADC hitsMICEEvent contains 0001 tracks, 0002 space points, 0006 slab hits, 0014 digits, 0055 VME TDC hits, and 0168 VME FADC hits
MICEEvent contains 0003 tracks, 0003 space points, 0006 slab hits, 0013 digits, 0054 VME TDC hits, and 0168 VME FADC hits
MICEEvent contains 0000 tracks, 0000 space points, 0001 slab hits, 0002 digits, 0031 VME TDC hits, and 0168 VME FADC hits
MICEEvent contains 0000 tracks, 0000 space points, 0000 slab hits, 0000 digits, 0000 VME TDC hits, and 0000 VME FADC hits
MICEEvent contains 0000 tracks, 0000 space points, 0000 slab hits, 0000 digits, 0000 VME TDC hits, and 0000 VME FADC hits
MICEEvent contains 0000 tracks, 0000 space points, 0000 slab hits, 0000 digits, 0000 VME TDC hits, and 0000 VME FADC hits
- ERROR in MDpartEventV1731::Init: INVALID particle Event **
- ERROR in MDpartEventV1731::Init: INVALID particle Event **
Data Word : 0x92929292
Unpacking exception
ERROR in MDpartEventV1731::Init: INVALID particle Event *
terminate called after throwing an instance of 'MDexception'
Aborted
I have tried different runs using the same inputs described in the original post. I am using valid runs which I have used before (eg 2522,2880).
I can put in a try-catch statement to complete the runs and bypass bad events, hopefully not losing too much useful information. I'll be running over many runs tonight and tomorrow so hopefully this will work out.
Updated by Karadzhov, Yordan over 12 years ago
The code that is now in the launchpad repository is not stable. It crashes every time when we have empty V1731 event (header without payload). These empty events are produced by one broken flashADC bord. Of course this will be fixed with the new version of the unpacking, by unfortunately this new version is completely incompatible with the DateReader in G4MICE. This mean that the only stable version of the unpacking for G4MICE is the one that comes with the original tarball file.
Updated by Rogers, Chris over 12 years ago
- Category set to common_cpp
- Assignee set to Karadzhov, Yordan
- Target version set to Future MAUS release
So the answer is - build in 32 bit for now. Sorry about that. It's something we're fixing, but legacy code is an issue still.
Is that a good enough answer?
Updated by Forrest, David over 12 years ago
- Status changed from Open to Closed
- % Done changed from 0 to 100
Thanks Yordan, that makes sense and means I'm not missing anything in these events.
Chris: I'm happy with applying the 64 bit swop that ChrisT suggested and using my own exception handler to catch headers with no payload, as a workaround. So far it seems to be doing the trick.
I've set this to closed. If you mean to leave it open so that it can be recorded for the next versions just reset it.
Updated by Tunnell, Christopher over 12 years ago
At present, if you can get the code to spit something out that your thesis committee likes? Wonderful. But don't write a journal article on it :)
Updated by Rogers, Chris over 12 years ago
- Target version changed from Future MAUS release to MAUS-v0.0.3