| ID |
Date |
Author |
Topic |
Subject |
|
389
|
11 Jun 2007 |
Stefan Ritt | Forum | crash when analyzing multiple runs offline | > I have hunted down "my" segfault problem to the fact that I book histograms not
> in <module>_init, but in <module>_bor. I have to do so, because only in bor do I
> know which histograms to book, as this information comes from the ODB (booking
> only histograms for CAMAC modules which were set to "read" in the ODB). The core
> dump happens on the first access (->Fill, ->SetName,...) of one of these histos
> in the 2nd run analyzed offline ("./analyzer -r n m").
>
> In mana.c:bor (line 1854) is stated that "all ROOT objects created by user module
> bor() functions go to the output file", and then does a gManaOutputFile->cd();
> Consequently, the histograms vanish after the file is closed, therefore the
> segfault when trying to access them in the 2nd run. (I keep track of existing
> histograms, only booking the missing histos in bor.)
>
> The problem goes away with "gROOT->cd()" in <module>_bor, before fiddling with
> TFolders and booking the histogram.
ROOT has the strange concept of "current working directory", coming from the fact that
ROOT was written by Fortran and PAW people, being used to have directories and
subdirectories with a persistent state (not really object-oriented style). So one can
set the "current working directory" to the root (=memory) with gROOT->cd() and to a
subdirectory which will later be written into a file with gManaOutputFile->cd(). If
you do the first one, the histograms are created only in memory, while in the later
case they are also created in memory, but will later be written into the output file
in the routine CloseRootOutputFile(). So if you do a gROOT->cd() in <module>_bor,
these histograms will not be written to file. So I guess your solution is not a real
solution.
> I do, however, not really understand the intention why histos booked in bor() go
> to only the file, whereas histos booked in init() go to memory. Could you please
> comment briefly? Maybe I missed the most important point. And what about online
> mode, should this work?
The root output file is opened in bor() and closed in eor(). For a histo to go to the
file, it must be booked after opening the file, that is after bor() in mana.c and
therefore after the gManaOutputFile->cd().
I agree with you that the current scheme is not satisfactory. When running online, you
want to keep the histos between the runs. When running offline, you delete and
re-create them for each run. It would be better to create all histos online and
offline under gROOT, and just copy them to gManaOutputFile before writing them. I have
to admit that this root code was never really used in a productive environment for
offline analysis, so there might be some issues here and there. Some people write
directly root files in the logger, and then do a root-only (without the midas
analyzer) analysis. Unfortunately I'm busy these days and cannot write any code right
now. But if you feel like something should be modified in mana.c, please send it to me
and I can incorporate it into the standard code. |
|
390
|
12 Jun 2007 |
Randolf Pohl | Forum | crash when analyzing multiple runs offline | Hi
> So I guess your solution is not a real solution.
I was not precise enough on what I do. This way the histograms persist in memory, but
they are also written to every file:
e.g. in module "trig_tdc":
TDirectory *savedir = gDirectory; // will restore this afterwards
gROOT->cd(); // go to file
// make sure we are in the right "analyzer module folder"
TDC_Folder = (TFolder *) gROOT->FindObjectAny("trig_tdc");
gHistoFolderStack->Add((TObject *) TDC_Folder);
...(loop over all TDCs, figure out which histos exist, and which need to be booked)
open_subfolder("raw4208");
hrTDC = h1_book(....); // create histo in memory, but it shows up in the file, too.
close_subfolder(); //raw4208
// restore gHistoFolderStack (we added a folder when entering routine)
gHistoFolderStack->Remove(gHistoFolderStack->Last());
// restore current directory
savedir->cd();
When deleting histos I do:
gManaHistosFolder->RecursiveRemove(*pHisto);
(*pHisto)->Delete();
(*pHisto) = NULL; // for my book-keeping of existing histos.
You don't have to clear the histos explicitly between runs. gManaHistosFolder does this
magic to you.
> But if you feel like something should be modified in mana.c, please send it to me
> and I can incorporate it into the standard code.
No, the code is fine. I just wanted to explain my problem and a solution to it, because
I thought that somebody might run into the same problem, too.
Ciao,
Randolf |
|
395
|
12 Jul 2007 |
Konstantin Olchanski | Forum | Midas on a x86_64 - incompatible with x86_32 | > We run 64-bit MIDAS on RHEL4 with 64-bit ROOT and everything generally works,
> except for compatibility problems with 32-bit MIDAS.
>
> The big problem is that 64-bit and 32-bit ODB turned out to be incompatible ...
I have now identified 3 data structures that change size when compiled with "-m64":
EVENT_REQUEST: stores a pointer to a function. Pointer size is 4 bytes with -m32 and 8 bytes with -m64.
This structure is part of an array inside BUFFER_HEADER, resulting in a sizable size mismatch between 32
bit and 64 bit shared memory data buffers.
The fix is simple: the function pointer is not used anywhere. Replace is with a "DWORD unused_filler"
makes -m32 and -m64 data buffers compatible. (But breaks compatibility with previous -m64 compiled midas).
CHN_SETTINGS and CHN_STATISTICS: apparently, -m32 and -m64 GCC has different packing rules and in -m64
mode, 4 bytes of padding are added to these data structures. Size size mismatch appears to be benign,
but will result in "size mismatch" complaints from ODB.
The fix is simple: adding "__attribute__ ((__packed__))" to the definition of the data structure makes
-m64 identical to -m32.
The "svn diff" of changes involved is attached below.
The biggest problem here is that making 32-bit ODB and 64-bit ODB compatible requires breaking one or
the other (My proposed changes break the 64-bit version. Alternatively, one could add explicit padding
to these data structures and break the 32-bit ODB).
I think it is important to make 32-bit and 64-bit code compatible: at TRIUMF we have to use a mixed
environment because out latest host computers all run 64-bit Linux while all our VME processors and all
older machines can only run 32-bit code; this incompatibility causes us weekly headaches.
Any thoughts?
K.O.
(this output of svn diff is doctored for clarity)
ladd00:midas$ svn diff
Index: include/midas.h
===================================================================
--- include/midas.h (revision 3744)
+++ include/midas.h (working copy)
- void (*dispatch) (HNDLE, HNDLE, EVENT_HEADER *, void *);
+ INT unused; // was void (*dispatch) (HNDLE, HNDLE, EVENT_HEADER *, void *);
} EVENT_REQUEST;
--- include/msystem.h (revision 3744)
+++ include/msystem.h (working copy)
+#define PACKED __attribute__ ((__packed__)) <--- this goes into midas.h inside the #ifdef "we use GCC"
-typedef struct {
+typedef struct PACKED { ... CHN_SETTINGS
-typedef struct {
+typedef struct PACKED { ... CHN_STATISTICS |
|
396
|
13 Jul 2007 |
Stefan Ritt | Forum | Midas on a x86_64 - incompatible with x86_32 | > The biggest problem here is that making 32-bit ODB and 64-bit ODB compatible requires breaking one or
> the other (My proposed changes break the 64-bit version. Alternatively, one could add explicit padding
> to these data structures and break the 32-bit ODB).
>
> I think it is important to make 32-bit and 64-bit code compatible: at TRIUMF we have to use a mixed
> environment because out latest host computers all run 64-bit Linux while all our VME processors and all
> older machines can only run 32-bit code; this incompatibility causes us weekly headaches.
>
> Any thoughts?
I agree to make 32-bit and 64-bit compatible. In the long run, everything will be 64-bit, so I would suggest
in breaking the 32-bit ODB, add some padding there where needed, probably with some conditional compiling.
This ensures to keep the native 64-bit packing, which probably will be somehow optimized for 64-bit
architectures and therefore might be a bit faster in the long run, when most systems are 64-bit. After this
has been implemented and well tested, I would go with an official announcement of the 32-bit break in the ODB,
and release a new version, so people can update from a TAR file if necessary. Existing ODB's can be converted
to the new format by exporting them in XML form and importing them again after the upgrade. |
|
399
|
12 Aug 2007 |
Konstantin Olchanski | Forum | Midas on a x86_64 - incompatible with x86_32 | > I agree to make 32-bit and 64-bit compatible. In the long run, everything will be 64-bit, so I would suggest
> in breaking the 32-bit ODB, add some padding there where needed, probably with some conditional compiling.
I now have the patches to implement this. Changes turned out to be minimal:
1) midas.h: remove unused field "dispatch" from EVENT_REQUEST and bump DATABASE_VERSION from 2 to 3
2) msystem.h: add 32-bit padding to CHN_STATISTICS and CHN_SETTINGS
(Pedantic note: the C/C++ languages permit compilers to arbitrary pad data members inside structures and one is
not supposed to rely on the specific layout of "struct"s, they could changing from day to day depending on
compiler vendor, version, 32/64 bit, optimization level, etc. This is quite silly, but I guess it was the only way
"they" could agree on a standard)
In practice, compilers are will behaved and one can follow simple rules and stay out of trouble.
1) if all data members are of the same size -> no padding
2) do not use "double" (64-bit) and "short" (16-bit), make all char[] arrays divisible by 4 -> size of everything
is 32-bit, see rule 1
3) if you have to use "short", they have to come in pairs to keep everything else aligned to 32-bit
4) if you have to use "double" (or uint64_t), keep them aligned to 64-bit, i.e. struct { int a,b,c; double x;} is
*bad* (4-byte padding may be added between c and x). struct { int a,b,c,d; double x; } is good.
Below are is "svn diff include/midas.h include/msystem.h". These changes have been tested on SL4 32-bit and
64-bit, SL5 32/64, F7 32/64 and SL4/ICC (Intel compiler) 32 bit and 64 bit.
The testing was done by adding checks on sizes of all struct's kept on ODB, i.e.
assert(sizeof(CHN_SETTINGS ) == 640); // ODB v3 with padding
assert(sizeof(CHN_STATISTICS ) == 32); // ODB v3 with padding
... etc ...
K.O.
ladd03:midas$ svn diff include/midas.h include/msystem.h
Index: include/midas.h
===================================================================
--- include/midas.h (revision 3798)
+++ include/midas.h (working copy)
@@ -38,7 +38,7 @@
* @{ */
/* has to be changed whenever binary ODB format changes */
-#define DATABASE_VERSION 2
+#define DATABASE_VERSION 3
/* MIDAS version number which will be incremented for every release */
#define MIDAS_VERSION "2.0.0"
@@ -810,8 +810,6 @@
short int event_id; /**< event ID */
short int trigger_mask; /**< trigger mask */
INT sampling_type; /**< GET_ALL, GET_SOME, GET_FARM */
- /**< dispatch function */
- void (*dispatch) (HNDLE, HNDLE, EVENT_HEADER *, void *);
} EVENT_REQUEST;
typedef struct {
Index: include/msystem.h
===================================================================
--- include/msystem.h (revision 3798)
+++ include/msystem.h (working copy)
@@ -454,6 +454,7 @@
INT event_id;
INT trigger_mask;
DWORD event_limit;
+ INT pad; // FIXME 64-bit "double" should be 64-bit aligned
double byte_limit;
double tape_capacity;
char subdir_format[32];
@@ -465,6 +466,7 @@
double bytes_written;
double bytes_written_total;
INT files_written;
+ INT pad; // FIXME pad data structure to be 64-bit aligned
} CHN_STATISTICS;
typedef struct {
ladd03:midas$ |
|
400
|
20 Aug 2007 |
Konstantin Olchanski | Forum | Midas on a x86_64 - incompatible with x86_32 | > > I agree to make 32-bit and 64-bit compatible. In the long run, everything will be 64-bit, so I would suggest
> > in breaking the 32-bit ODB, add some padding there where needed, probably with some conditional compiling.
>
> I now have the patches to implement this. Changes turned out to be minimal:
>
> 1) midas.h: remove unused field "dispatch" from EVENT_REQUEST and bump DATABASE_VERSION from 2 to 3
> 2) msystem.h: add 32-bit padding to CHN_STATISTICS and CHN_SETTINGS
The padding of CHN_STATISTICS and CHN_SETTINGS is not working right - somehow mhttpd and mlogger keep recreating the
data in ODB and erasing the padding fields. I am looking into this.
K.O. |
|
403
|
29 Aug 2007 |
Konstantin Olchanski | Forum | ODBv3, second try - Midas on a x86_64 - incompatible with x86_32 | > > > I agree to make 32-bit and 64-bit compatible. In the long run, everything will be 64-bit, so I would suggest
> > > in breaking the 32-bit ODB, add some padding there where needed, probably with some conditional compiling.
> > 1) midas.h: remove unused field "dispatch" from EVENT_REQUEST and bump DATABASE_VERSION from 2 to 3
> > 2) msystem.h: add 32-bit padding to CHN_STATISTICS and CHN_SETTINGS
I am now trying a different solution of to fixing the issue of CHN_STATISTICS and CHN_SETTINGS changing size.
1) midas.h: (same as before) remove unused field "dispatch" from EVENT_REQUEST and bump DATABASE_VERSION from 2 to 3
2) msystem.h: in CHN_STATISTICS and CHN_SETTINGS change type of "event_limit" and "files_written" from int to "double".
Below are the latest ODBv3 meta patches:
ladd03:midas$ svn diff
Index: include/midas.h
===================================================================
--- include/midas.h (revision 3844)
+++ include/midas.h (working copy)
/* has to be changed whenever binary ODB format changes */
-#define DATABASE_VERSION 2
+#define DATABASE_VERSION 3
.........
short int trigger_mask; /**< trigger mask */
INT sampling_type; /**< GET_ALL, GET_SOME, GET_FARM */
- /**< dispatch function */
- void (*dispatch) (HNDLE, HNDLE, EVENT_HEADER *, void *);
} EVENT_REQUEST;
Index: include/msystem.h
===================================================================
--- include/msystem.h (revision 3845)
+++ include/msystem.h (working copy)
-"Event limit = DWORD : 0",\
+"Event limit = DOUBLE : 0",\
..................
-"Files written = INT : 0",\
+"Files written = DOUBLE : 0",\
..................
- DWORD event_limit;
+ double event_limit;
..................
- INT files_written;
+ double files_written;
K.O. |
|
412
|
17 Oct 2007 |
Randolf Pohl | Forum | Adding MIDAS .root-files | Dear MIDAS users,
I want to add several .root-files produced by the MIDAS analyzer, in a fast
and convenient way. ROOT's hadd fails because it does not know how to treat
TFolders. I guess this problem is not unique to me, so I hope that somebody of
you might already have found a solution.
Why don't I just run "analyzer -r 1 10000"?
We have taken lots of runs under (rapidly) varying conditions, so it would be
lots of "-r". And the analysis is quite involved, so rerunning all data takes
about one hour on a fast PC making this quite painful.
Therefore, I would like to rerun all data only once, and then add the result
files depending on different criteria.
Of course, I tried to write a script that does the adding. But somehow it is
incredibly slow. And I am not the Master Of C++, too.
Is there any deeper reason for MIDAS using TFolders, not TDirectorys? ROOT's
hadd can treat TDirectory. Can I simply patch "my" MIDAS? Is there general
interest in a change like this? (Does anyone have experience with the speed of
hadd?)
Looking forward to comments from the Forum.
Cheers,
Randolf |
|
413
|
17 Oct 2007 |
Randolf Pohl | Forum | Multi-core CPUs | Dear Forum,
I have this beautiful Intel Quadcore with fast disks, but MIDAS does obviously
only make use of one CPU at a time. Has anyboy of you already done some work
on making MIDAS parallel? Event-based data analysis should be the best
candidate for this.
Has anybody done this with PVM? There is some PVM-related stuff in the MIDAS
sources, but I got the impression this works only with HBOOK, not with ROOT.
Or am I wrong?
But then PVM is probably also not the most efficient thing one ONE machine
with multiple CPUs, right? And finally, with PVM we're back to
adding .root-files efficiently (see my previous post).
Any thoughts?
Cheers,
Randolf |
|
414
|
17 Oct 2007 |
Stefan Ritt | Forum | Multi-core CPUs | > I have this beautiful Intel Quadcore with fast disks, but MIDAS does obviously
> only make use of one CPU at a time. Has anyboy of you already done some work
> on making MIDAS parallel? Event-based data analysis should be the best
> candidate for this.
There are ring buffer routines rb_xxx for distributed event analysis, but this is
currently only implemented in the front-end framework. These routines are pretty
simple, and their integration into the analyzer should not be very difficult.
Unfortunately I don't have time for that right now. We do our analysis such that we
analyze four different runs in parallel on a quadcore machine.
- Stefan |
|
415
|
17 Oct 2007 |
John M O'Donnell | Forum | Adding MIDAS .root-files | The following program handles regular directories in a file, or folders (ugh).
Most histograms are added bin by bin.
For scaler events it is convenient to see the counts as a function of time (ala
sclaer history plots in mhttpd). If the histogram looks like a scaler plot versus
time, then new bins are added on to the end (or into the middle!) of the histogram.
All different versions of cuts are kept.
TTrees are not explicitly supported, so probably don't do the right thing...
John.
> Dear MIDAS users,
>
> I want to add several .root-files produced by the MIDAS analyzer, in a fast
> and convenient way. ROOT's hadd fails because it does not know how to treat
> TFolders. I guess this problem is not unique to me, so I hope that somebody of
> you might already have found a solution.
>
> Why don't I just run "analyzer -r 1 10000"?
> We have taken lots of runs under (rapidly) varying conditions, so it would be
> lots of "-r". And the analysis is quite involved, so rerunning all data takes
> about one hour on a fast PC making this quite painful.
> Therefore, I would like to rerun all data only once, and then add the result
> files depending on different criteria.
>
> Of course, I tried to write a script that does the adding. But somehow it is
> incredibly slow. And I am not the Master Of C++, too.
>
> Is there any deeper reason for MIDAS using TFolders, not TDirectorys? ROOT's
> hadd can treat TDirectory. Can I simply patch "my" MIDAS? Is there general
> interest in a change like this? (Does anyone have experience with the speed of
> hadd?)
>
> Looking forward to comments from the Forum.
>
> Cheers,
>
> Randolf |
| Attachment 1: histoAdd.cxx
|
#include <iostream>
#include <vector>
#include <iterator>
#include <cstring>
using namespace std;
#include "TROOT.h"
#include "TFile.h"
#include "TString.h"
#include "TDirectory.h"
#include "TObject.h"
#include "TClass.h"
#include "TKey.h"
#include "TH1.h"
#include "TAxis.h"
#include "TMath.h"
#include "TCutG.h"
#include "TFolder.h"
bool verbose (false);
TFolder *histosFolder (0);
//==============================================================================
void addObject (TObject *o, const TString &prefix, TFolder *opFolder=0);
/** called for each file to do the addition.
* loops over each object in the file, and
* uses addObject to dispatch the actuall addition.
*/
void add (TFile *file, const TString &prefix) {
//------------------------------------------------------------------------------
TString dirName (file->GetName());
if (verbose) cout << " scanning TFile" << endl;
TString newPrefix (prefix + dirName + "/");
TIter i (file->GetListOfKeys());
while (TKey *k = static_cast<TKey *>( i())) {
TObject *o (file->Get( k->GetName()));
addObject( o, newPrefix);
}
return;
}
//==============================================================================
/** Most histograms are added bin by bin, but if simpleAdd == false,
* the xaxis values are assumed different, in which case we look up
* appropriate bin numbers, and use a new extended xaxis if needed.
*
* Use simpleAdd=false to accumulate scaler rate histograms.
*/
void add (const TH1 *newh, TH1 *&hsum, TFolder *opFolder) {
//------------------------------------------------------------------------------
const bool simpleAdd (newh->GetXaxis()->GetTimeDisplay() ? false : true);
if (!hsum) {
hsum = (TH1 *)newh->Clone();
TString title = "histoAdd: ";
title += hsum->GetTitle();
if (opFolder) hsum->SetDirectory( 0);
}
else if (simpleAdd) hsum->Add( newh);
else { // extend axis - for 1D histos with equal sized bins
size_t nBinsSum = hsum->GetNbinsX();
size_t nBinsNew = newh->GetNbinsX();
vector<Double_t>bin_contents;
vector<Double_t>histo_edges;
Int_t holder_bins;
/* foundBin is either the overflow bin (if the 2 histograms don't overlap)
* or it is the bin number in histoA that has the same low edge as the
* lowest bin edge in histoB. The only time that histograms can overlap
* is when the older scaler.cxx is used to create the histograms with
* fixed bin sizes.
*/
Int_t foundBin = hsum->FindBin( newh->GetBinLowEdge(1) );
histo_edges.resize(foundBin);
bin_contents.resize(foundBin);
for( int i = 1; i <= foundBin; i++ ) {
histo_edges[i-1] = hsum->GetBinLowEdge(i);
bin_contents[i-1] = hsum->GetBinContent(i);
}
if(foundBin < nBinsSum) {
//the histos overlap or we have already made holder bins
holder_bins = 0;
}
else {
//create a "place holder" histo
Int_t width = 10;
holder_bins = (int)((newh->GetXaxis()->GetXmin()
- hsum->GetXaxis()->GetXmax())/width);
if( holder_bins < width ) holder_bins = width;
TH1F *bin_holder = new TH1F("bin_holder", "bin_holder", holder_bins,
hsum->GetXaxis()->GetXmax(),
newh->GetXaxis()->GetXmin() );
histo_edges.resize( foundBin + holder_bins );
bin_contents.resize( foundBin + holder_bins );
for( int i = 0; i < holder_bins; i++ ) {
histo_edges[foundBin+i] = bin_holder->GetBinLowEdge(i+2);
bin_contents[foundBin+i] = 0;
}
delete bin_holder;
} //end else
histo_edges.resize( foundBin + holder_bins + nBinsNew+1 );
bin_contents.resize( foundBin + holder_bins + nBinsNew+1 );
for( int i = 0; i <= nBinsNew; i++ ) {
histo_edges[i+foundBin+holder_bins] = newh->GetBinLowEdge(i+1);
bin_contents[i+foundBin+holder_bins] = newh->GetBinContent(i+1);
}
hsum->SetBins( histo_edges.size()-1, &histo_edges[0] );
for ( int i=1; i<histo_edges.size(); ++i) {
hsum->SetBinContent( i, bin_contents[i-1]);
}
if (opFolder) {
//opFolder->Remove( hsum);
//opFolder->Add( exth);
hsum->SetDirectory( 0);
}
}
if (verbose) {
if (simpleAdd) cout << " adding counts";
else cout << " tagging on bins";
cout << endl;
}
return;
}
//==============================================================================
/** Most cuts are written out just once, but if a cut is different from
* the most recently written version of a cut with the same name, then
* another copy of the cut is written out. Thus if a cut changes during
* a series of runs, all versions of the cut will be present in the
* summed file.
*/
void add (const TCutG *o, TCutG *&oOut, TFolder *opFolder) {
//------------------------------------------------------------------------------
const char *name (o->GetName());
bool write (false);
if (!oOut) write = true;
else {
Int_t n (o->GetN());
if (n != oOut->GetN()) write = true;
else {
double x1, x2, y1, y2;
for (Int_t i=0; i<n; ++i) {
o ->GetPoint( i, x1, y1);
oOut->GetPoint( i, x2, y2);
if ((x1 != x2) || (y1 != y2)) write = true;
}
}
}
if (write) {
if (verbose) {
if (oOut) cout << " changed";
cout << " TCutG" << endl;
}
if (!opFolder) {
oOut = const_cast<TCutG *>( o);
o->Write( name, TObject::kSingleKey);
} else {
TCutG *clone = static_cast<TCutG *>( o->Clone());
if (oOut) opFolder->Add( clone);
oOut = clone;
}
} else if (verbose) cout << endl;
return;
}
//==============================================================================
/** for most objects, we keep just the first version.
*/
void add (const TObject *o, TObject *&oSum, TFolder *opFolder) {
//------------------------------------------------------------------------------
const char *name (o->GetName());
if (!oSum) {
if (verbose) cout << " saving TObject" << endl;
if (!opFolder) o->Write( name, TObject::kSingleKey);
} else {
if (verbose) cout << endl;
}
return;
}
//==============================================================================
/** create the new directory and then start adding its contents
*/
void add (TDirectory *dir, TDirectory *&sumDir,
TFolder *opFolder, const TString &prefix) {
//------------------------------------------------------------------------------
TDirectory *currentDir (gDirectory);
TString dirName (dir->GetName());
if (verbose) cout << " scanning TDirectory" << endl;
TString newPrefix (prefix + dirName + "/");
if (!sumDir) sumDir = gDirectory->mkdir( dirName);
sumDir->cd();
TIter i (dir->GetListOfKeys());
while (TKey *k = static_cast<TKey *>( i())) {
TObject *o (dir->Get( k->GetName()));
addObject( o, newPrefix, opFolder);
}
currentDir->cd();
return;
}
//==============================================================================
/** create a new folder and then start adding its contents
*/
void add (const TFolder *folder, TFolder *&sumFolder,
TFolder *parentFolder, const TString &prefix) {
//------------------------------------------------------------------------------
if (verbose) cout << " scanning TFolder" << endl;
const char *name (folder->GetName());
TString newPrefix (prefix + name + "/");
if (!sumFolder) sumFolder = new TFolder (name, name);
if (!histosFolder) histosFolder = sumFolder;
TIter i (folder->GetListOfFolders());
while (TObject *o = i()) addObject( o, newPrefix, sumFolder);
return;
}
//==============================================================================
int main (int argc, char **argv) {
//------------------------------------------------------------------------------
if (argc < 3) {
cerr << argv[0] << ": out_root_file in_root_file1 in_root_file2 ..." << endl;
return 1;
}
TROOT root ("histoadd", "histoadd");
root.SetBatch();
TString opFileName (argv[1]);
TFile *opFile (TFile::Open( opFileName, "RECREATE"));
if (!opFile) {
cerr << argv[0] << ": unable to open file: " << argv[1] << endl;
return 1;
}
--argc;
++argv;
... 95 more lines ...
|
|
417
|
21 Nov 2007 |
Konstantin Olchanski | Forum | ODBv3, second try - Midas on a x86_64 - incompatible with x86_32 |
These changes to make 32-bit and 64-bit ODB binary compatible with each other are now commited to midas svn, revision 4080.
Starting with this revision, ODB version changes from 2 to 3, breaking binary compatibility with previous releases.
Before upgrading to this revision, save your ODB as an XML file, *and* try to reload it, to catch any potential problems with parsing of the XML file.
Part of this commit are checks for sizes of important midas data structures stored in ODB shared memory - if the compiled size does not match the expected
value, binary compatibility is broken and the program will abort - to avoid further corruption of ODB shared memory. This feature is only enabled on Linux and
it is expected to trigger only on compiler malfunctions (generates wrong data size) and on accidental or intentional changes to important data structures in
midas, to warn the user that they broke ODB binary compatibility.
K.O.
> > > > I agree to make 32-bit and 64-bit compatible. In the long run, everything will be 64-bit, so I would suggest
> > > > in breaking the 32-bit ODB, add some padding there where needed, probably with some conditional compiling.
> > > 1) midas.h: remove unused field "dispatch" from EVENT_REQUEST and bump DATABASE_VERSION from 2 to 3
> > > 2) msystem.h: add 32-bit padding to CHN_STATISTICS and CHN_SETTINGS
>
> I am now trying a different solution of to fixing the issue of CHN_STATISTICS and CHN_SETTINGS changing size.
>
> 1) midas.h: (same as before) remove unused field "dispatch" from EVENT_REQUEST and bump DATABASE_VERSION from 2 to 3
> 2) msystem.h: in CHN_STATISTICS and CHN_SETTINGS change type of "event_limit" and "files_written" from int to "double".
>
> Below are the latest ODBv3 meta patches:
>
> ladd03:midas$ svn diff
> Index: include/midas.h
> ===================================================================
> --- include/midas.h (revision 3844)
> +++ include/midas.h (working copy)
> /* has to be changed whenever binary ODB format changes */
> -#define DATABASE_VERSION 2
> +#define DATABASE_VERSION 3
> .........
> short int trigger_mask; /**< trigger mask */
> INT sampling_type; /**< GET_ALL, GET_SOME, GET_FARM */
> - /**< dispatch function */
> - void (*dispatch) (HNDLE, HNDLE, EVENT_HEADER *, void *);
> } EVENT_REQUEST;
>
> Index: include/msystem.h
> ===================================================================
> --- include/msystem.h (revision 3845)
> +++ include/msystem.h (working copy)
> -"Event limit = DWORD : 0",\
> +"Event limit = DOUBLE : 0",\
> ..................
> -"Files written = INT : 0",\
> +"Files written = DOUBLE : 0",\
> ..................
> - DWORD event_limit;
> + double event_limit;
> ..................
> - INT files_written;
> + double files_written;
>
> K.O. |
|
420
|
04 Feb 2008 |
Robert Pattie | Forum | analyzer crashes at high rates | I'm using midas to read data from a waveform digitizer at event rates of
10-30kHz. To accomplish this the digitizer is read via Block transfers and the
raw data put into a single MIDAS event. Thus a MIDAS event could contain upto
250 physical events and at maximum 350kBytes. In the analyzer modules I had
been analyzing the first physics event contained in a MIDAS event with no
problem. Recently I tried to analyze all the physical events. At low rates,
100hz-1khz, this was no problem, 1-5 physical events in a MIDAS event. At
higher rates 10-20kHz, where there are about 40physical events per MIDAS event,
the analyzer keeps up for a few seconds then seg faults with " 'shared object
read from target memory' has disappear; keeping it symbols". Any suggestions as
to why the analyzer is crashing would be very helpful.
Thanks,
Robert |
|
421
|
05 Feb 2008 |
Stefan Ritt | Forum | analyzer crashes at high rates | > I'm using midas to read data from a waveform digitizer at event rates of
> 10-30kHz. To accomplish this the digitizer is read via Block transfers and the
> raw data put into a single MIDAS event. Thus a MIDAS event could contain upto
> 250 physical events and at maximum 350kBytes. In the analyzer modules I had
> been analyzing the first physics event contained in a MIDAS event with no
> problem. Recently I tried to analyze all the physical events. At low rates,
> 100hz-1khz, this was no problem, 1-5 physical events in a MIDAS event. At
> higher rates 10-20kHz, where there are about 40physical events per MIDAS event,
> the analyzer keeps up for a few seconds then seg faults with " 'shared object
> read from target memory' has disappear; keeping it symbols". Any suggestions as
> to why the analyzer is crashing would be very helpful.
I personally have never seen this error message. The analyzer is designed such that
it produces "back pressure" if the data rate is higher than the analysis rate and
you have "request all events" on. The only thing I can image are the following two
issues:
- At higher rate where you have more than 40 physical events per MIDAS event, there
is some bug in your analysis code which gets exploited only in that case. Maybe some
temporary array which is only 35 entries long or something like this.
- The back pressure mentioned above will slow down the frontend. If your computer
busy logic is not working correctly, you might get more triggers than you can
acquire. Maybe then the data gets screwed up and the analyzer chokes on it.
Finding the exact reason is not simple. For sure you have to run the analyzer inside
the debugger, to see exactly where the segfault happens. You then maybe have to
produce some dummy data in the frontend (like always sending the same event) to
disentangle some possible trigger problems from other problems.
Best regards,
Stefan |
|
424
|
05 Feb 2008 |
qinzeng peng | Forum | rpc timeout, related to event_size and watch dog? need help | Dear all,
I'm trying to write a simulation code on midas. What I did is just modify the
frontend.c(pp) from experiment samples and made some parameters change on midas.h .
Because my simulation ask for about 4.5MB for each event, so I increase the
MAX_EVENT_SIZE and max_event_size accordingly.
in midas.h :
#define MAX_EVENT_SIZE 0xa00000 //0x400000 /**< maximum event size 4MB*/
#define BANKLIST_MAX 640 //64 /**< max # of banks in event */
#define DEFAULT_RPC_TIMEOUT 60000 //10000
#define WATCHDOG_INTERVAL 5000 //1000
#define DEFAULT_WATCHDOG_TIMEOUT 60000 /**< Watchdog */
in frontend.cpp :
BOOL frontend_call_loop = TRUE;
INT max_event_size = 5 * 1024 * 1024;
INT max_event_size_frag = 2* max_event_size;
INT event_buffer_size = 2 * max_event_size;
EQUIPMENT equipment[] = {
{"WFD_SIMU", /* equipment name */
{1, 0, /* event ID, trigger mask */
"SYSTEM", /* event buffer */
#ifdef USE_INT
EQ_INTERRUPT, /* equipment type */
#else
EQ_POLLED, /* equipment type */
#endif
LAM_SOURCE(0, 0xFFFFFF), /* event source crate 0, all stations */
"MIDAS", /* format */
TRUE, /* enabled */
RO_RUNNING, // | /* read only when running */
// RO_ODB, /* and update ODB */
5000, /* poll for 500ms */
0, /* stop run after this event limit */
0, /* number of sub events */
0, /* don't log history */
"", "", "",},
read_simu_event, /* readout routine */
},
......
}
INT frontend_loop()
{
/* if frontend_call_loop is true, this routine gets called when
the frontend is idle or once between every event */
ss_sleep(100);
return SUCCESS;
}
Compilation OK and running mlogger, odbedit, frontend is OK.
start the run -> no problem ( but there is a long waiting time in frontend if
starting the run. Before the run begins, frontend terminal popping up messages
frequently, say, every 10 seconds. When run starts, frontend terminal hang on
for a couple of minutes before popping up next bunch of messages.)
stop the run -> Problem -> rpc timeout
message from odbedit:
[qzpeng@phy2-dhcp140 simu]$ odbedit -s 10000000
12:54:27 [WFD Simu,INFO] Program WFD Simu on host phy2-dhcp140 started
12:54:37 [Logger,INFO] Program Logger on host phy2-dhcp140 started
[local:simu:S]/>start
Run number [1]: 7
Are the above parameters correct? ([y]/n/q):
Starting run #7
Run #7 started
[local:simu:R]/>stop
[midas.c:9231:rpc_client_call,ERROR] rpc timeout, routine = "rc_transition",
host = "phy2-dhcp140.bu.edu"
Error: Unknown error 504 from client 'WFD Simu' on host phy2-dhcp140.bu.edu
[local:simu:R]/>
runing message from frontend:
[qzpeng@phy2-dhcp140 simu]$ ./frontend
Frontend name : WFD Simu
Event buffer size : 10485760
System max event size : 10485760
User max event size : 5242880
User max frag. size : 10485760
# of events per buffer : 2
Connect to experiment...
OK
Init hardware...
...... |
|
425
|
06 Feb 2008 |
Stefan Ritt | Forum | rpc timeout, related to event_size and watch dog? need help | Most likely you changed the maximal event size in midas.h, but you did not re-compile all programs. The maximal event size goes into the size of the shared memory buffer, so all participating programs have to have the same setting, especially the mserver program. So do the following:
- update to the latest midas version, which is revision 4116
- modify in your midas.h only MAX_EVENT_SIZE. The other settings you modified might have bad side effects. If you increase the RPC timeout, the error will still happen, just later. It comes from the fact that you sent too big events the the server (or the logger), which refuses to take the big events or simply crashes, so the RPC call never returns and after the timeout you get the error.
- recompile all midas programs, don't forget the mserver program
- run the standard demo frontend from the distribution
I tried the above and it just worked fine for me. |
|
426
|
06 Feb 2008 |
qinzeng peng | Forum | rpc timeout, related to event_size and watch dog? need help |
| Stefan Ritt wrote: | | Most likely you changed the maximal event size in midas.h, but you did not re-compile all programs. |
Every time I changed midas.h or system header files, I did the re-compile with following procedure:
ipcrm
rm .*.SHM
mcleanup
make clean
make
su
make install
| Stefan Ritt wrote: | | The maximal event size goes into the size of the shared memory buffer, so all participating programs have to have the same setting, especially the mserver program. |
Question here:
How to compile mserver seperately? I think make and make install under midas directory already did the job.
| Stefan Ritt wrote: | | update to the latest midas version, which is revision 4116 |
I used latest svn version, so I believe I'm using the latest version 4116.
svn co svn+ssh://svn@savannah.psi.ch/afs/psi.ch/project/meg/svn/midas/trunk midas
svn co svn+ssh://svn@savannah.psi.ch/afs/psi.ch/project/meg/svn/mxml/trunk mxml
I followed your instructions and did the following:
1)
svn co svn+ssh://svn@savannah.psi.ch/afs/psi.ch/project/meg/svn/midas/trunk midas
svn co svn+ssh://svn@savannah.psi.ch/afs/psi.ch/project/meg/svn/mxml/trunk mxml
2)
changed two parameters in midas.h
#define MAX_EVENT_SIZE 0xa00000 //0x400000 /**< maximum event size 4MB->10MB*/
#define BANKLIST_MAX 640 //64 /**< max # of banks in event, I need 356 */
3) make
su
make install
I don't know if I need compile mserver seperately.
4) running only two programs:
odbedit -s 10000000
./frontend
And I still got the same problem as before.
[qzpeng@phy2-dhcp140 simu]$ odbedit -s 10000000
[local:simu:S]/>ls
System
Programs
Experiment
Logger
Runinfo
Alarms
[local:simu:S]/>mkdir Equipment
12:44:12 [WFD Simu,INFO] Program WFD Simu on host phy2-dhcp140 started
[local:simu:S]/>start
Run number [1]:
Are the above parameters correct? ([y]/n/q):
Starting run #1
Run #1 started
[local:simu:R]/>stop
[midas.c:9231:rpc_client_call,ERROR] rpc timeout, routine = "rc_transition", host = "phy2-dhcp140.bu.edu"
Error: Unknown error 504 from client 'WFD Simu' on host phy2-dhcp140.bu.edu
[local:simu:R]/>
And I know that the run stopped after a while on frontend, but after the eroor message showed above. If I tried to stop again in odb after a while, it did stopped.
[local:simu:R]/>stop
Run #1 stopped
By the way, thanks for the quick response. I've been working on this for a couple of weeks and I am a newbie.
I also attached my frontend.cpp code and output of make with warning message but comilation completed. Thanks in advance.
In frontend.cpp I only use simulation and don't need any hardware realted issue or function calls but I jsut leave some of them there. |
| Attachment 1: frontend.cpp
|
/********************************************************************\
Name: frontend.c
Created by: Stefan Ritt
Contents: Experiment specific readout code (user part) of
Midas frontend. This example simulates a "trigger
event" and a "scaler event" which are filled with
CAMAC or random data. The trigger event is filled
with two banks (ADC0 and TDC0), the scaler event
with one bank (SCLR).
$Id: frontend.c 3384 2006-10-21 04:29:18Z amaudruz $
Modifed by: qp Jan/20/2008 for simulation
Jan 21, add on ROOT
method: keep old C functions in extern "C" {}
define new c++ funcions with ROOT
read pulse shape from pulseTemplate#.txt
\********************************************************************/
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <time.h>
#include "midas.h"
//#include "mcstd.h"
#include "experim.h"
#include <string.h>
/* ROOT include */
#include "TSystem.h"
#include "TROOT.h"
#include "TFile.h"
#include "TH1.h"
#include "TH2.h"
#include "WFDIndex.h"
WFDIndex *myWFDIndex;
/* for WFD Simu */
const INT n_fills=5000; /*** number of fills per segment from ODB ***/
const INT n_pulses_max=30;
INT n_pulses = 30; /*** number of muons decayed in one fill ***/
const int N_WFD=340;
const int N_SHAPE=2400;
const int N_ISLAND=24;
int N_STEP = N_SHAPE/N_ISLAND;
int debug = 1; // 0 for no message, 1 for message, 2 for verbose message
typedef struct {
char ADC[24];
DWORD separator;
DWORD time;
} ISLAND;
static ISLAND island, island_random;
ISLAND gIsland[N_WFD][n_fills*n_pulses_max+1];
INT gCount[N_WFD];
float gShape[N_WFD][N_SHAPE];
INT gPeak[N_WFD];
TFile *f, *fout;
char histname0[80], histname[80];
/* make frontend functions callable from the C framework */
#ifdef __cplusplus
extern "C" {
#endif
#include "mcstd.h"
/*-- Globals -------------------------------------------------------*/
/* The frontend name (client name) as seen by other MIDAS clients */
char *frontend_name = "WFD Simu"; //"Sample Frontend";
/* The frontend file name, don't change it */
char *frontend_file_name = __FILE__;
/* frontend_loop is called periodically if this variable is TRUE */
BOOL frontend_call_loop = TRUE;
/* a frontend status page is displayed with this frequency in ms */
INT display_period = 3000;
/* maximum event size produced by this frontend */
INT max_event_size = 5 * 1024 * 1024;
/* maximum event size for fragmented events (EQ_FRAGMENTED) */
INT max_event_size_frag = 2* max_event_size;
/* buffer size to hold events */
INT event_buffer_size = 2 * max_event_size;
/* number of channels */
#define N_ADC 4
#define N_TDC 4
#define N_SCLR 4
/* CAMAC crate and slots */
#define CRATE 0
#define SLOT_IO 23
#define SLOT_ADC 1
#define SLOT_TDC 2
#define SLOT_SCLR 3
/*-- Function declarations -----------------------------------------*/
INT frontend_init();
INT frontend_exit();
INT begin_of_run(INT run_number, char *error);
INT end_of_run(INT run_number, char *error);
INT pause_run(INT run_number, char *error);
INT resume_run(INT run_number, char *error);
INT frontend_loop();
INT read_simu_event(char *pevent, INT off);
INT read_scaler_event(char *pevent, INT off);
void register_cnaf_callback(int debug);
INT poll_event(INT source, INT count, BOOL test);
INT interrupt_configure(INT cmd, INT source, POINTER_T adr);
/*-- Equipment list ------------------------------------------------*/
#undef USE_INT
EQUIPMENT equipment[] = {
{"WFD_SIMU", /* equipment name */
{1, 0, /* event ID, trigger mask */
"SYSTEM", /* event buffer */
#ifdef USE_INT
EQ_INTERRUPT, /* equipment type */
#else
EQ_POLLED, /* equipment type */
#endif
LAM_SOURCE(0, 0xFFFFFF), /* event source crate 0, all stations */
"MIDAS", /* format */
TRUE, /* enabled */
RO_RUNNING, // | /* read only when running */
// RO_ODB, /* and update ODB */
5000, /* poll for 500ms */
0, /* stop run after this event limit */
0, /* number of sub events */
0, /* don't log history */
"", "", "",},
read_simu_event, /* readout routine */
},
{"Scaler", /* equipment name */
{2, 0, /* event ID, trigger mask */
"SYSTEM", /* event buffer */
EQ_PERIODIC | EQ_MANUAL_TRIG, /* equipment type */
0, /* event source */
"MIDAS", /* format */
TRUE, /* enabled */
RO_RUNNING | RO_TRANSITIONS | /* read when running and on transitions */
RO_ODB, /* and update ODB */
10000, /* read every 10 sec */
0, /* stop run after this event limit */
0, /* number of sub events */
0, /* log history */
"", "", "",},
read_scaler_event, /* readout routine */
},
{""}
};
#ifdef __cplusplus
}
#endif
INT wfd_get_shape(void);
INT wfd_get_hist(void);
double wfd_get_random(int sn, int choice);
/********************************************************************\
Callback routines for system transitions
These routines are called whenever a system transition like start/
stop of a run occurs. The routines are called on the following
occations:
frontend_init: When the frontend program is started. This routine
should initialize the hardware.
frontend_exit: When the frontend program is shut down. Can be used
to releas any locked resources like memory, commu-
nications ports etc.
begin_of_run: When a new run is started. Clear scalers, open
rungates, etc.
end_of_run: Called on a request to stop a run. Can send
end-of-run event and close run gates.
pause_run: When a run is paused. Should disable trigger events.
resume_run: When a run is resumed. Should enable trigger events.
\********************************************************************/
/*-- Frontend Init -------------------------------------------------*/
INT frontend_init()
{
/* hardware initialization */
cam_init();
cam_crate_clear(CRATE);
cam_crate_zinit(CRATE);
/* enable LAM in IO unit */
camc(CRATE, SLOT_IO, 0, 26);
/* enable LAM in crate controller */
cam_lam_enable(CRATE, SLOT_IO);
/* reset external LAM Flip-Flop */
camo(CRATE, SLOT_IO, 1, 16, 0xFF);
camo(CRATE, SLOT_IO, 1, 16, 0);
/* register CNAF functionality from cnaf_callback.c with debug output */
register_cnaf_callback(1);
/* print message and return FE_ERR_HW if frontend should not be started */
wfd_get_hist();
wfd_get_shape();
myWFDIndex = new WFDIndex();
return SUCCESS;
}
/*-- Frontend Exit -------------------------------------------------*/
INT frontend_exit()
{
return SUCCESS;
}
/*-- Begin of Run --------------------------------------------------*/
INT begin_of_run(INT run_number, char *error)
{
/* put here clear scalers etc. */
island.ADC[0] = 5;
island.ADC[1] = 6;
island.ADC[2] = 7;
island.ADC[3] = 5;
island.ADC[4] = 7;
island.ADC[5] = 20;
island.ADC[6] = 30;
island.ADC[7] = 50;
island.ADC[8] = 90;
island.ADC[9] = 120;
island.ADC[10] = 150;
island.ADC[11] = 200;
island.ADC[12] = 165;
island.ADC[13] = 130;
island.ADC[14] = 110;
island.ADC[15] = 90;
island.ADC[16] = 30;
island.ADC[17] = 10;
island.ADC[18] = 7;
island.ADC[19] = 4;
island.ADC[20] = 6;
island.ADC[21] = 5;
island.ADC[22] = 3;
island.ADC[23] = 6;
//island.ADC[24] = 7;
//island.ADC[25] = 6;
//island.ADC[26] = 6;
//island.ADC[27] = 7;
//island.ADC[28] = 5;
//island.ADC[29] = 5;
//island.ADC[30] = 6;
//island.ADC[31] = 5;
island.separator = 0x0;
island.time = 0x00010001;
// wfd_get_hist();
return SUCCESS;
}
INT wfd_get_hist(void)
{
gROOT->Reset();
char filename0[] = "IslandParameters";
char runname[] = "57140-57170";
... 338 more lines ...
|
| Attachment 2: make-output.txt
|
[qzpeng@phy2-dhcp140 midas]$ make
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/midas.o src/midas.c
src/midas.c: In function ¡Æbm_open_buffer¡Ç:
src/midas.c:4020: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/midas.c: In function ¡Ærpc_server_connect¡Ç:
src/midas.c:8259: warning: pointer targets in passing argument 3 of ¡Ægetsockname¡Ç differ in signedness
src/midas.c:8261: warning: pointer targets in passing argument 3 of ¡Ægetsockname¡Ç differ in signedness
src/midas.c:8263: warning: pointer targets in passing argument 3 of ¡Ægetsockname¡Ç differ in signedness
src/midas.c:8376: warning: pointer targets in passing argument 3 of ¡Æaccept¡Ç differ in signedness
src/midas.c:8378: warning: pointer targets in passing argument 3 of ¡Æaccept¡Ç differ in signedness
src/midas.c:8380: warning: pointer targets in passing argument 3 of ¡Æaccept¡Ç differ in signedness
src/midas.c: In function ¡Ærpc_register_server¡Ç:
src/midas.c:10533: warning: pointer targets in passing argument 3 of ¡Ægetsockname¡Ç differ in signedness
src/midas.c: In function ¡Ærpc_server_accept¡Ç:
src/midas.c:11230: warning: pointer targets in passing argument 3 of ¡Æaccept¡Ç differ in signedness
src/midas.c:11239: warning: pointer targets in passing argument 3 of ¡Ægetpeername¡Ç differ in signedness
src/midas.c: In function ¡Ærpc_client_accept¡Ç:
src/midas.c:11493: warning: pointer targets in passing argument 3 of ¡Æaccept¡Ç differ in signedness
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/system.o src/system.c
src/system.c: In function ¡Æss_suspend_init_ipc¡Ç:
src/system.c:2948: warning: pointer targets in passing argument 3 of ¡Ægetsockname¡Ç differ in signedness
src/system.c: In function ¡Æss_suspend¡Ç:
src/system.c:3416: warning: pointer targets in passing argument 6 of ¡Ærecvfrom¡Ç differ in signedness
src/system.c:3443: warning: pointer targets in passing argument 6 of ¡Ærecvfrom¡Ç differ in signedness
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/mrpc.o src/mrpc.c
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/odb.o src/odb.c
src/odb.c: In function ¡Ædb_open_database¡Ç:
src/odb.c:891: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/odb.c: In function ¡Ædb_lock_database¡Ç:
src/odb.c:1441: warning: dereferencing type-punned pointer will break strict-aliasing rules
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/ybos.o src/ybos.c
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/ftplib.o src/ftplib.c
src/ftplib.c: In function ¡Æftp_data¡Ç:
src/ftplib.c:288: warning: pointer targets in passing argument 3 of ¡Ægetsockname¡Ç differ in signedness
src/ftplib.c:310: warning: pointer targets in passing argument 3 of ¡Æaccept¡Ç differ in signedness
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/mxml.o ../mxml/mxml.c
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/cnaf_callback.o src/cnaf_callback.c
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/history.o src/history.c
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/alarm.o src/alarm.c
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/elog.o src/elog.c
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/strlcpy.o ../mxml/strlcpy.c
rm -f linux/lib/libmidas.a
ar -crv linux/lib/libmidas.a linux/lib/midas.o linux/lib/system.o linux/lib/mrpc.o linux/lib/odb.o linux/lib/ybos.o linux/lib/ftplib.o linux/lib/mxml.o linux/lib/cnaf_callback.o linux/lib/history.o linux/lib/alarm.o linux/lib/elog.o linux/lib/strlcpy.o
a - linux/lib/midas.o
a - linux/lib/system.o
a - linux/lib/mrpc.o
a - linux/lib/odb.o
a - linux/lib/ybos.o
a - linux/lib/ftplib.o
a - linux/lib/mxml.o
a - linux/lib/cnaf_callback.o
a - linux/lib/history.o
a - linux/lib/alarm.o
a - linux/lib/elog.o
a - linux/lib/strlcpy.o
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/mana.o src/mana.c
g++ -DUSE_ROOT -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -pthread -m32 -I/usr/root/include -o linux/lib/rmana.o src/mana.c
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/mfe.o src/mfe.c
src/mfe.c: In function ¡Æscheduler¡Ç:
src/mfe.c:1869: warning: pointer targets in passing argument 5 of ¡Ædb_get_value¡Ç differ in signedness
src/mfe.c:2042: warning: pointer targets in passing argument 5 of ¡Ædb_get_value¡Ç differ in signedness
src/mfe.c:2051: warning: pointer targets in passing argument 5 of ¡Ædb_get_value¡Ç differ in signedness
g++ -Dextname -DMANA_LITE -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/fal.o src/fal.c
src/fal.c:106: warning: non-local variable ¡Æ<anonymous struct> out_info¡Ç uses anonymous type
src/fal.c: In function ¡ÆINT midas_log_open(LOG_CHN*, INT)¡Ç:
src/fal.c:1194: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/fal.c: In function ¡ÆINT dump_log_open(LOG_CHN*, INT)¡Ç:
src/fal.c:1582: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/fal.c: In function ¡ÆINT ascii_log_open(LOG_CHN*, INT)¡Ç:
src/fal.c:1803: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/fal.c: At global scope:
src/fal.c:3064: warning: non-local variable ¡Æ<anonymous struct> eb¡Ç uses anonymous type
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mserver src/mserver.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mhttpd src/mhttpd.c src/mgd.c linux/lib/libmidas.a -lutil -lpthread -lz -lm
g++ -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mlogger src/mlogger.c linux/lib/libmidas.a -L/usr/root/lib -lCore -lCint -lRIO -lNet -lHist -lGraf -lGraf3d -lGpad -lTree -lRint -lPostscript -lMatrix -lPhysics -pthread -lm -ldl -rdynamic -Wl,-rpath,/usr/root/lib -lutil -lpthread -lz
src/mlogger.c: In function ¡ÆINT midas_log_open(LOG_CHN*, INT)¡Ç:
src/mlogger.c:1094: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/mlogger.c: In function ¡ÆINT dump_log_open(LOG_CHN*, INT)¡Ç:
src/mlogger.c:1530: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/mlogger.c: In function ¡ÆINT ascii_log_open(LOG_CHN*, INT)¡Ç:
src/mlogger.c:1750: warning: dereferencing type-punned pointer will break strict-aliasing rules
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/odbedit src/odbedit.c src/cmdedit.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mtape utils/mtape.c linux/lib/libmidas.a -lutil -lpthread -lz
utils/mtape.c: In function ¡Ætape_dir¡Ç:
utils/mtape.c:84: warning: dereferencing type-punned pointer will break strict-aliasing rules
utils/mtape.c:87: warning: dereferencing type-punned pointer will break strict-aliasing rules
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mhist utils/mhist.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mstat utils/mstat.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mcnaf utils/mcnaf.c drivers/camac/camacrpc.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mdump utils/mdump.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/lazylogger src/lazylogger.c linux/lib/libmidas.a -lutil -lpthread -lz
g++ -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mhdump utils/mhdump.cxx
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mchart utils/mchart.c linux/lib/libmidas.a -lutil -lpthread -lz
cp -f utils/stripchart.tcl linux/bin/.
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/webpaw utils/webpaw.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/odbhist utils/odbhist.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/melog utils/melog.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mlxspeaker utils/mlxspeaker.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/dio utils/dio.c
[qzpeng@phy2-dhcp140 midas]$
|
|
427
|
06 Feb 2008 |
Stefan Ritt | Forum | rpc timeout, related to event_size and watch dog? need help | First of all, I would appreciate if you do not post your entry ten times. Each time you edit it, you produce an email notification going to everybody, so people might get annoyed to receive too many emails from you. Think what you want to write and then post once.
Second, I told you to use the frontend from the distribution, but you used your own code. Since I successfully ran the demo frontend with the large event size, the origin of your problem must be "in between". So start with the demo frontend, try it, then modify its buffer size in frontend.c, then try again. When I told to to recompile midas, I meant you should also recompile your front-end each time you change midas.h. The mserver is automatically recompiled when you recompile and install midas (just check the /usr/local/bin/mserver date and time to confirm that it got updated during your last "make install"). Then add things from your specific front-end program step by step to see at which step the problem occurs the first time. This gives you some hint where the real cause lies. |
|
485
|
05 Jun 2008 |
Jimmy Ngai | Forum | CAEN VME-USE Bridge with MIDAS | Hi All,
Is there any example code for using MIDAS with the CAEN VME-USB Bridge V1718?
Thanks.
Regards,
Jimmy |
|
486
|
07 Jun 2008 |
Jimmy Ngai | Forum | CAEN VME-USE Bridge with MIDAS | Hi All,
I am testing the libraries provided by CAEN with the sample softwares in the
bundle CD. The Windows sample program works fine, but I cannot get started with
the Linux sample program. When I run CAENVMEDemo in Scientific Linux 5.1, it
gives me a message "Error opening the device". I have followed the instructions
in CAENVMElibReadme.txt:
- compile and load the device driver v1718.ko
- install the library libCAENVME.so
Does anyone have any experience of using V1718 in Scientific Linux? Thanks.
Regards,
Jimmy
> Hi All,
>
> Is there any example code for using MIDAS with the CAEN VME-USB Bridge V1718?
> Thanks.
>
> Regards,
> Jimmy |
|