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
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;
402 cleanup();
404 blockid = ls.readLong();
405 ntot = ls.readLong();
406 version = ls.readString(len);
407 if (blockid != LSH_EVENTHEADER) ls.setError(LSH_NOEVENT);
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
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 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.


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: Tue Dec 10 09:05:24 Pacific Standard Time 2019
.:: Contact :: Home ::.

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