Reconsider scan command: catch seg fault in structure_5 in quad precision with gfortran 4.7.0

[Juergen Reuter]

|  |  |  |  +  KEYWORD     '=>'  = [keyword] =>
|  |  |  |  +  SEQUENCE    <expr>  =  <term>
|  |  |  |  |  +  SEQUENCE    <term>  =  <factor>
|  |  |  |  |  |  +  SEQUENCE    <factor>  =  <integer_value>
|  |  |  |  |  |  |  +  SEQUENCE    <integer_value>  =  <integer_literal>
|  |  |  |  |  |  |  |  +  INTEGER     <integer_literal>  = 900
|  |  |  |  +  SEQUENCE    <step_spec>  =  '/+/' <expr>
|  |  |  |  |  +  KEYWORD     '/+/'  = [keyword] /+/

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7FA3B76DDE97
#1  0x7FA3B76DE464
#2  0x3A0BA3299F
#3  0x7FA43258E700
#4  0x7FA43258E73F
#5  0x7FA432AA2B5D
#6  0x7FA432AA896C
#7  0x7FA432AF9CB0
#8  0x7FA432AF99CE
#9  0x7FA433D984AD
#10  0x7FA433D9905E
#11  0x3A0BA1ED1C
./run_whizard.sh: line 26: 11311 Segmentation fault      (core dumped) ../src/whizard --logfile $basename.log --no-banner --library ${libname}_lib --rebuild $* $script.sin
91,105c91,103
< sqrts =  2.500000000000E+02
< sqrts =  3.000000000000E+02
< sqrts =  3.500000000000E+02
< sqrts =  4.000000000000E+02
< sqrts =  4.500000000000E+02
< sqrts =  5.000000000000E+02
< sqrts =  6.000000000000E+02
< sqrts =  7.000000000000E+02
< sqrts =  8.000000000000E+02
< sqrts =  9.000000000000E+02
< sqrts =  1.000000000000E+03
< sqrts =  1.000000000000E+04
< sqrts =  1.000000000000E+05
< | WHIZARD run finished.
< |=============================================================================|
---
> sqrts =  0.000000000000E+00
> sqrts =  0.000000000000E+00
> sqrts =  0.000000000000E+00
> sqrts =  0.000000000000E+00
> sqrts =  0.000000000000E+00
> sqrts =  0.000000000000E+00
> sqrts =  0.000000000000E+00
> sqrts =  0.000000000000E+00
> sqrts =  0.000000000000E+00
> sqrts =  0.000000000000E+00
> sqrts =  0.000000000000E+00
> sqrts =  0.000000000000E+00
> sqrts =  0.000000000000E+00

[Juergen Reuter]

In 4.7.3 it doesn't segfault with quadruple precision, but it gives the wrong output:

91,103c91,103
< sqrts =  2.500000000000E+02
< sqrts =  3.000000000000E+02
< sqrts =  3.500000000000E+02
< sqrts =  4.000000000000E+02
< sqrts =  4.500000000000E+02
< sqrts =  5.000000000000E+02
< sqrts =  6.000000000000E+02
< sqrts =  7.000000000000E+02
< sqrts =  8.000000000000E+02
< sqrts =  9.000000000000E+02
< sqrts =  1.000000000000E+03
< sqrts =  1.000000000000E+04
< sqrts =  1.000000000000E+05
---
> sqrts =  0.000000000000E+00
> sqrts =  0.000000000000E+00
> sqrts =  0.000000000000E+00
> sqrts =  0.000000000000E+00
> sqrts =  0.000000000000E+00
> sqrts =  0.000000000000E+00
> sqrts =  0.000000000000E+00
> sqrts =  0.000000000000E+00
> sqrts =  0.000000000000E+00
> sqrts =  0.000000000000E+00
> sqrts =  0.000000000000E+00
> sqrts =  0.000000000000E+00
> sqrts =  0.000000000000E+00

This is a blocker :((((

[Juergen Reuter]

This works both with 4.9.0 and 4.8.0. So it seems that only 4.7.x (entirely) has a problem with it.

[Juergen Reuter]

So what do we do with this? Veto against 4.7.x and quadruple? or, WK, could you try to program around this ugly thingy... ?

[Juergen Reuter]

I might have a viable solution: throwing a warning for scanning in quadruple precision with gfortran 4.7 and disabling the corresponding test in that case. Hope all worked fine.

[Juergen Reuter]

Done as described above in r5095. Closing (if someone is unhappy, we can open it again.)

[kilian]

happens that I've solved the problem at the same time you were checking in the warning stuff .. testing right now

[kilian]

ok, tests run nevertheless. That was an unfortunate coincidence -- should I remove the warning again?

[Juergen Reuter]

It killed several of my hours. VERY UNFORTUNATE and again a severe crash. IFFFF you are sure you can remove all the changes correctly, I did (incl. ./update etc.) then go ahead. Could you also do the show(real)???? Just in case we clash again. What about the gfortran bug report. I'm frustrated like hell ...

[Juergen Reuter]

BTW, Jenkins is going down for hours now.... Marco is not reachable. So no checks at the moment. I don't know what to do.

[Juergen Reuter]

When does this happen???? Tests also with 4.7.0?????

[kilian]

sorry - but I didn't know you were working on this (was offline). The last message I got was

WK, could you try to program around this ugly thingy... ?

so I tried.

The resolution is simple. In gfortran 4.7, polymorphic scalars are ok, but polymorphic arrays are broken. So I wouldn't trust the original code in any case. I eliminated the polymorphic array at the cost of only a slight increase in complexity. The finalizer is now also reinstated and works with 4.7.2, showing that the memory corruption issue was really there, even for the tests that did work.

[Juergen Reuter]

Again, time is AWFULLY sparse: what about 4.7.0? what about the warnings? and the configure changes? (Jenkins back up again, understood what was wrong. Was a configuration error)

[kilian]

My current minimal solution which I would like to check in: keep the m4/fortran.m4 macro (I added a comment and run ./update, no other mod), but disable it in configure.ac

This macro may be become useful if we encounter another difficulty w/ 4.7 etc. Just in case.

After I removed the polymorphic array, I guess it will work with 4.7.0. This I can't check. I did check double+quadruple w/ 4.7.2.

[Juergen Reuter]

What about the tests dir??? Close to check in myself now. Eliminated all the stuff again from fortran.m4 !!!!

[Juergen Reuter]

Dachte ich mir .... Scheissdreck da !!!!

[Juergen Reuter]

Corrected the corrections of the corrections of the clashes of the corrections to the clashes ... All seems to work now again. Closing.

[kilian]

@JR: Thanks!