Linear Collider Forum



Home » Software Tools » LCIO » stdehepjob fails on 64 bit
warning.gif  stdehepjob fails on 64 bit [message #1495] Fri, 06 June 2008 02:07 Go to previous message
poeschl
Messages: 22
Registered: June 2004
Location: LAL Orsay
Dear Experts,

executing the stdhepjob on a 64 bit machine leads to a segmentation
fault while it runs fine if one compiles on a 64 bit machine
using the -m32 option, i.e. creating a 32bit version.

I have traced the error down to


long lStdHep::Event::read(lStdHep &ls)
396 {
397 //
398 // Read event header
399 //
400 long len;
401
402 cleanup();
403
404 blockid = ls.readLong();
405 ntot = ls.readLong();
406 version = ls.readString(len);
407 if (blockid != LSH_EVENTHEADER) ls.setError(LSH_NOEVENT);
408
409 evtnum = ls.readLong();
410 storenum = ls.readLong();

where the 32 and 64 bit output for 'evtnum' and 'storenum'
deviate during the second passage of this method.
The program fails finally at another point but still the point above would be the first where agreement has to be assured.

The method in turn calls methods from the lXDR class which indeed
doesn't look very portable, see e.g.


114 long lXDR::checkRead(long *l)
115 {
116 if (_openForWrite) return(_error = LXDR_READONLY);
117 if (_fp == 0) return(_error = LXDR_NOFILE);
118 if (l) {
119 long nr;
120 if ((nr = fread(l, 4, 1, _fp)) != 1) return(_error = LXDR_READERROR);
121 *l = ntohl(*l);
122 }
123 return(LXDR_SUCCESS);
124 }

which assumes a long to be 4 byte while in fact a long has 8 byte on a 64 bit machine. Also the application of fread and
fwrite leads to non-portable methods, i,e,

[poeschl@lx2 UTIL]$ man fread
...
APPLICATION USAGE
The ferror() or feof() functions must be used to distinguish between an error condition and an
end-of-file condition.

Because of possible differences in element length and byte ordering, files written using
fwrite() are application-dependent, and possibly cannot be read using fread() by a different
application or by the same application on a different processor.


Does anybody know how to fix the bug? In any case I believe that we need to revise this class completely as 64 bit
machines are getting more and more common.

I observe the same behaviour for lcio v01-08-02, v01-09 and v01-10, always compiled following the instructions on the lcio website, for both cmake or classical building.

Infos about my architecture

[poeschl@lx2 UTIL]$ uname -a
Linux lx2.lal.in2p3.fr 2.6.9-42.0.3.ELlargesmp #1 SMP Thu Oct 5 16:46:10 CDT 2006 x86_64 x86_64 x86_64 GNU/Linux

with a standard SLC4 installation.


Cheers,

Roman
 
Read Message warning.gif
Read Message
Read Message
Previous Topic:Counting Events in an LCIO File
Next Topic:Strange behaviour of LCEvent::takeCollection()
Goto Forum:
  


Current Time: Wed Oct 17 04:32:16 Pacific Daylight Time 2018
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.1.
Copyright ©2001-2010 FUDforum Bulletin Board Software