unknown material - segfault - material is garbage

[Laurie Nevay]

The lattice is parsed without error, but when bdsim builds the material, it exit(1) at unknown material for that element. Reordering the arguments for that beamline element avoids this. The material is printed out and it's filled with bits of text from elsewhere in the input .gmad file.

-------- EEEE ------- G4Exception-START -------- EEEE ------- *** G4Exception : -1 issued by : BDSMaterials::GetMaterial - Material , l=0.647; mba18r3b1: not known. Aborting.

Fatal Exception core dump *** -------- EEEE -------- G4Exception-END --------- EEEE -------

To reproduce - run attached lattice bdsim --file=3.5tev_h.gmad --batch --circular --output=root --outfile=t1

Look at lines:1384 in 3.5tev_components.gmad

[Laurie Nevay]

Also from the farm, the same original error I witnessed:

-------- EEEE ------- G4Exception-START -------- EEEE ------- *** G4Exception : -1 issued by : BDSMaterials::GetMaterial - Material a18r3b1: sextupole, k not known. Aborting.

Fatal Exception core dump *** -------- EEEE -------- G4Exception-END --------- EEEE -------

[Jochem Snuverink]

I had a look at this and can reproduce. Something already goes wrong in the parser. With debug output:

params,VARIABLE (material) = str (, l=0.647; MBA18R3B1:)

Interesting, adding a space/symbol to any (also commented!) line in the 3.5tev_components.gmad before line 1384 prevents the crash. This probably indicates a buffer overflow or memory overwrite.

I ran with valgrind but nothing particular came up, and nothing in the parser.

[Jochem Snuverink]

upgrading to major as parser can't be fully trusted at the moment.

[Laurie Nevay]

Cheers for looking into this!!

So I can get round it by adding space beforehand or commenting out a random line before that line??

I just a way for it to work just now.

I may try splitting into smaller files tomorrow. Was also going to try using only portions of the line.

See you tomorrow,

Laurie

[Laurie Nevay]

A simple example where a collimator is defined but not used produces the error:

main> Using input file : d.gmad Warning : unknown parameter : "material" BDSGlobalConstants::Instance() synchRadOn = 0 BDSGlobalConstants::BDSGlobalConstants> synchTrackphotons = 0

The object is a collimator defined with:

c1: rcol, l=10m, ysize=5mm, xsize=5*mm, material="Copper";

Moving the material definition earlier in the list of parameters, removes the warning and it's built correctly.

[Laurie Nevay]

example file for simple machine with collimator description issue

[Jochem Snuverink]

yes that is a bug i also found yesterday. it is not serious though, caused by a forgotten else. the right material is actually added. i will push my commit.

[Jochem Snuverink]

here is more output from the parser reading in the faulty line. pretty mind-boggling to me. First the string "Graphite" is read in correctly. And then the string is different when interpreted (both in bold). Not much happened in between.

Stack now 0

Entering state 1

Reading a token: Next token is token VARIABLE ("TCSGB5R3B1")

Shifting token VARIABLE ("TCSGB5R3B1")

Entering state 8

Reading a token: Next token is token ':' (<>)

Shifting token ':' (<>)

Entering state 45

Reading a token: Next token is token RCOL (<>)

Shifting token RCOL (<>)

Entering state 105

Reading a token: Next token is token ',' (<>)

Shifting token ',' (<>)

Entering state 217

Reading a token: Next token is token VARIABLE ("material")

Shifting token VARIABLE ("material")

Entering state 143

Reading a token: Next token is token '=' (<>)

Shifting token '=' (<>)

Entering state 228

Reading a token: Next token is token STR ("Graphite")

Shifting token STR ("Graphite")

Entering state 270

Reading a token: Next token is token ',' (<>)

Shifting token ',' (<>)

Entering state 294

Reading a token: Next token is token VARIABLE ("l")

Shifting token VARIABLE ("l")

Entering state 143

Reading a token: Next token is token '=' (<>)

Shifting token '=' (<>)

Entering state 228

Reading a token: Next token is token NUMBER (1)

Shifting token NUMBER (1)

Entering state 7

Reducing stack by rule 104 (line 1489):

$1 = token NUMBER (1)

-> $$ = nterm aexpr (1)

Stack now 0 1 8 45 105 217 143 228 270 294 143 228

Entering state 271

Reading a token: Next token is token ',' (<>)

Shifting token ',' (<>)

Entering state 295

Reading a token: Next token is token VARIABLE ("xsize")

Shifting token VARIABLE ("xsize")

Entering state 143

Reading a token: Next token is token '=' (<>)

Shifting token '=' (<>)

Entering state 228

Reading a token: Next token is token NUMBER (0.00715)

Shifting token NUMBER (0.00715)

Entering state 7

Reducing stack by rule 104 (line 1489):

$1 = token NUMBER (0.00715)

-> $$ = nterm aexpr (0.00715)

Stack now 0 1 8 45 105 217 143 228 270 294 143 228 271 295 143 228

Entering state 271

Reading a token: Next token is token ',' (<>)

Shifting token ',' (<>)

Entering state 295

Reading a token: Next token is token VARIABLE ("ysize")

Shifting token VARIABLE ("ysize")

Entering state 143

Reading a token: Next token is token '=' (<>)

Shifting token '=' (<>)

Entering state 228

Reading a token: Next token is token NUMBER (0.2)

Shifting token NUMBER (0.2)

Entering state 7

Reducing stack by rule 104 (line 1489):

$1 = token NUMBER (0.2)

-> $$ = nterm aexpr (0.2)

Stack now 0 1 8 45 105 217 143 228 270 294 143 228 271 295 143 228 271 295 143 228

Entering state 271

Reading a token: Next token is token ';' (<>)

Reducing stack by rule 70 (line 759):

$1 = token VARIABLE ("ysize")

$2 = token '=' (<>)

$3 = nterm aexpr (0.2)

-> $$ = nterm parameters (<>)

Stack now 0 1 8 45 105 217 143 228 270 294 143 228 271 295 143 228 271 295

Entering state 324

Reducing stack by rule 67 (line 520):

$1 = token VARIABLE ("xsize")

$2 = token '=' (<>)

$3 = nterm aexpr (0.00715)

$4 = token ',' (<>)

$5 = nterm parameters (<>)

-> $$ = nterm parameters (<>)

Stack now 0 1 8 45 105 217 143 228 270 294 143 228 271 295

Entering state 324

Reducing stack by rule 67 (line 520):

$1 = token VARIABLE ("l")

$2 = token '=' (<>)

$3 = nterm aexpr (1)

$4 = token ',' (<>)

$5 = nterm parameters (<>)

-> $$ = nterm parameters (<>)

Stack now 0 1 8 45 105 217 143 228 270 294

Entering state 323

Reducing stack by rule 71 (line 870):

$1 = token VARIABLE ("material")

$2 = token '=' (<>)

$3 = token STR ("2*m, l=0.64")

$4 = token ',' (<>)

$5 = nterm parameters (<>)

-> $$ = nterm parameters (<>)

Stack now 0 1 8 45 105 217

Entering state 258

Reducing stack by rule 56 (line 447):

$1 = token RCOL (<>)

$2 = token ',' (<>)

$3 = nterm parameters (<>)

-> $$ = nterm rcol (<>)

Stack now 0 1 8 45

Entering state 131

Reducing stack by rule 26 (line 232):

$1 = token VARIABLE ("TCSGB5R3B1")

$2 = token ':' (<>)

$3 = nterm rcol (<>)

-> $$ = nterm decl (<>)

Stack now 0 1

[Laurie Nevay]

I always thought this problem occurred with very long input files, but it can' happen with shorter ones too. Interestingly, again this was with an ecol. Attached is a zipped directory with three models of the CLIC BDS.

"clicbds_parser.gmad" is the one that will fail.
"clicbds.gmad" is the same model, but with some extra whitespace at the end of the third line in the components file "clicbds_components.gmad", which solves the problem.

[Laurie Nevay]

Here is the CLIC BDS attachment

[Jochem Snuverink]

I had a look at this again. original example is no longer reproducible, but the CLIC-BDS one is.

I think that this is either due to an overflow in the parser either in the parser buffers or in the code itself (e.g. char overflow since both examples are with strings). For the latter I have replaced most char* with std::strings, but to no avail so far.

One option is to rewrite the parser into C++ since flex and bison now support that.

[Jochem Snuverink]

fix issue 25 : allocate (and free) memory for string input

→ <<cset 210d9c3d6276>>

[Jochem Snuverink]

hopefully this is fixed now. It seems there was no specific memory allocation for char string input in the parser. This could cause memory corruption.

[Jochem Snuverink]

fix issue 25 : allocate (and free) memory for string input

→ <<cset ff31ff2f2ce9>>