H2root problem with floating point exception

ROOT
1

Dear ROOT experts,
I met a problem while using h2root.
I generated a *.rz file with MCFM, when I used h2root to change it,
I always got the following information. Thank you very much for your help!

h2root hzz_tb_lord_ct10.00_80__80__126_te2-creat0__.rz hzz_tb_lord_ct10.00_80__80__126_te2-creat0__.rz.root
[i][i]Converting directory //example

CALL HRZKEY(IDN)
Converting RWN with ID= 300, nentries = 195

*** Break *** floating point exception

===========================================================
There was a crash.
This is the entire stack trace of all threads:

#0 0x0000003d7b2bcd3c in waitpid () from /lib64/libc.so.6
#1 0x0000003d7b242142 in do_system () from /lib64/libc.so.6
#2 0x00007f84bc5c1c59 in TUnixSystem::StackTrace() () from /home/wangyk/workdir/root-6.04.10/lib/libCore.so
#3 0x00007f84bc5c37cc in TUnixSystem::DispatchSignals(ESignals) () from /home/wangyk/workdir/root-6.04.10/lib/libCore.so
#4
#5 0x00000000004250c8 in hgnf_ ()
#6 0x00000000004055dd in convert_rwn(int) ()
#7 0x000000000040697d in convert_directory(char const*) ()
#8 0x00000000004044be in main ()

The lines below might hint at the cause of the crash.
If they do not help you then please submit a bug report at
root.cern.ch/bugs. Please post the ENTIRE stack trace
from above as an attachment in addition to anything else
that might help us fixing this issue.

#5 0x00000000004250c8 in hgnf_ ()
#6 0x00000000004055dd in convert_rwn(int) ()
#7 0x000000000040697d in convert_directory(char const*) ()
#8 0x00000000004044be in main ()
===========================================================[/i][/i]

2

Hi,

could you post the input file?

D

3

Do you mean the *.rz file?
I tried to put it in the attachment, however, I got the information
"Invalid file extension:…"

4

I changed the extension from .rz to .root, however, I got another problem with “file too large” while attach it.
The file is about 5M.

Thanks for any help!

5

Hi,

could you post it somewhere else, e.g. dropbox?
Without the file, it’s hard to make progress.

D

6

Here it is :

dl.dropboxusercontent.com/u/616 … reat0__.rz

And I repeat here the question I asked you by email:

do some files generated with MCFM work for you ?
If yes can you guess point some specificity in that one ?

7

Hi,
Thank you very much for posting the *.rz file.

I noticed the dswhbook.f(attched) in MCFM is used for booking histograms and ntuples.
The histogram has no problem while using h2root to transfer, but the ntuples have problem.
dswhbook.f (13.9 KB)

8

at line 449 of your program, can you make sur the values you pass to hfn are valid ?

9

I am not sure whether the values are valid or not.
So I commented all the assignment sentences from line 428 to line 445, such as

c do i=1,imaxmom
c pfill(4*(i-1)+1)=sngl(p(i+2,1))
c pfill(4*(i-1)+2)=sngl(p(i+2,2))
c pfill(4*(i-1)+3)=sngl(p(i+2,3))
c pfill(4*(i-1)+4)=sngl(p(i+2,4))
c enddo
c pfill(imaxmom4+1)=sngl(wt)
c pfill(imaxmom4+2)=sngl(wt_gg)
c pfill(imaxmom4+3)=sngl(wt_gq)
c pfill(imaxmom4+4)=sngl(wt_qq)
c pfill(imaxmom*4+5)=sngl(wt_qqb)

c— include PDF errors if necessary
c if (PDFerrors) then
c do i=1,ipdf
c pfill(imaxmom4+5+i)=sngl(wtPDFwgt(i)/PDFwgt(0))
c enddo
c endif

However, I still got the crash. I noticed it always crashes from " nentries = 195" .

10

In that case pfill might contain anything… including invalid numbers.
You better initialize it with fix known values.

11

also you have:

  real pfill(imaxmom*4+5+ipdf)

what is the value of imaxmom*4+5+ipdf ?

12

[quote=“couet”]also you have:

  real pfill(imaxmom*4+5+ipdf)

what is the value of imaxmom*4+5+ipdf ?[/quote]

imaximom is the final particle number, it is 4 or 6 for my case

13

Ok but I was wondering if the dimension of the vector was fine … i.e. the whole expression :

imaxmom*4+5+ipdf

can you print it to check ?

14

I changed line 409 parameter(batchlimit=1000000)
to parameter(batchlimit=200)
to limit the enetries in each ntuple. And get a lot of *rz file.

Surprisingly, there is no crash while using h2root for all files. see the attachment.
h2root.txt (118 KB)

15

That make me think that there is really a problem of corruption in the rz file itself.

16

I can see a potential problem.
In the “dswhbook.f”, I can see two places which call HLIMIT (and it may be executed multiple times, e.g. each time the “dswntuplebook” subroutine is called), but according to HLIMIT description it must be called before any other HBOOK routine.

Well, I don’t this it will help, but you could try to add one line in the “dswntuplebook” subroutine, after the “hropen” call and before the “if (ipdf .eq. 0) then” line:
call hcdir(’//HISTOS’,’ ')

17

[quote=“couet”][quote]
Surprisingly, there is no crash while using h2root for all files
[/quote]

That make me think that there is really a problem of corruption in the rz file itself.[/quote]

I am sorry that I may mislead you in the former post. I just found that there is no crash information in h2root.txt because the last *rz file (*287.rz) happen to have no events. When I set batchlimit=1000 (for example), I got crash information again in the last *rz file while other *rz files are good when using h2root to transfer.

18

[quote=“Pepe Le Pew”]I can see a potential problem.
In the “dswhbook.f”, I can see two places which call HLIMIT (and it may be executed multiple times, e.g. each time the “dswntuplebook” subroutine is called), but according to HLIMIT description it must be called before any other HBOOK routine.

Well, I don’t this it will help, but you could try to add one line in the “dswntuplebook” subroutine, after the “hropen” call and before the “if (ipdf .eq. 0) then” line:
call hcdir(’//HISTOS’,’ ')[/quote]

Thanks for the reply. I tried to add the sentence “call hcdir(’//HISTOS’,’ ')”, it doesn’t work, the crash still exists.

19

Also check (as Pepe pointed out) that HLIMIT is not called more than once… you have at least two calls to HLIMIT. It should be the fist call to initiate HBOOK and it should be called only once.

20

Well, maybe one could try to use a negative value (it will completely “reset” ZEBRA?), but I’m not really sure that even in this case you are allowed to call it multiple times (and I’m not sure that the very first call can use a negative value):
call hlimit(-NWPAWC)
Who was responsible for HBOOK? Rene? Fons?