Fork me on GitHub

Opened 7 years ago

Closed 7 years ago

#1132 closed Bug (fixed)

About a bug and a temporary debug in MacOS and clang

Reported by: tangyilei Owned by:
Priority: major Milestone:
Component: Delphes code Version: Delphes 3
Keywords: Cc:

Description

Dear authors,

I have tried to download the Delphes in the environment of MadGraph and unfortunately, this Delphes (3.4.1) does not work. Whenever I ran it, no matter through MadGraph or I directly ran it in bash, it just showed me an error message "Abort trap: 6", which usually appears when Array out of Bound appears in the clang compiler.

I tried to locate the bug, and finally found that it is due to the tcl contained by the Delphes. In tcl.h, there is a Tcl_HashEntry structure type with a union type "key" embedded in it. This "key" contains a string, with the definition of 4 characters, however, in tclHash.c, the function StringCreate(), when tcl need a longer key length, it just append bytes at the end of the Tcl_HashEntry when "calloc" a new Tcl_HashEntry object "hPtr" (Line 508 in tclHash.c). Although this will extend the length of hPtr, making it safe to copy a long key to the hPtr->key.string (Line 513) in most of the compilers. However, as for clang, the compiler mechanically believe that the length of the key.string should be 4, and regard any copying of a longer string as illegal.

I think to cure this problem might involve latest version of tcl, or request TCL developers to modify this problem. However, here I show a temporary method.

In tcl.h, line 797, modify char string[4]->char string[4096]. This will leave enough space for most of the key lengths.
In tclHash.c, line 508, quote /*+ strlen(key) - (sizeof(hPtr->key) -1)*/. This will generate Tcl_HashEntry objects without extensions of the lengths.

Finally, this works.

However, I believe that a final solution should be adopted. For example, change to a new tcl version, or automatically detect the compiler and then adopt different c source codes, etc. Since now, many more and more people are trying to migrate to the MacBook and the environment of clang during their daily researches.

Change History (4)

comment:1 by Pavel Demin, 7 years ago

Many thanks for finding the source of this problem.

I'm afraid that we won't be able to switch to a more recent version of Tcl. This particular version is the only one that has the exact combination of features that Delphes requires.

Even the most recent tcl.h contains mostly the same union in Tcl_HashEntry:
https://github.com/tcltk/tcl/blob/master/generic/tcl.h#L1181-L1199

It would be interesting to see the command line arguments that are passed to clang when it compiles Delphes and Tcl.

If there are arguments like -fsanitize=..., then the easiest solution would be to remove them.

comment:2 by mac, 7 years ago

I really appreciate tangyilei's help, his solution was very useful for me, and my problem was solved after applying the suggested changes; now delphes runs on MacOS Sierra without error! thanks alot

comment:3 by Pavel Demin, 7 years ago

After reading some C documentation and looking at different Tcl versions, I've found a very easy solution for this problem. It's enough to replace char string[4]; with char string[1]; on line 797 in external/tcl/tcl.h.

This fix is now in the master branch and in Delphes-3.4.1.tar.gz.

comment:4 by Pavel Demin, 7 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.