Triple gfortran problem

[Juergen Reuter]

There are three problems with gfortran in the commit v6897. With gfortran 4.8-LATEST and 4.9-LATEST there is either a segmentation fault or a WHIZARD bug in in the SINDARIN parser test, while for gfortran 4.7 there is another segmentation fault in object_logical_9.

[Juergen Reuter]

One of the two issues with gfortran 4.7 have been resolved in r6989, the other one is still pending. The other stuff is a true Heisenbug: in gdb I cannot reproduce it while it appears without gdb. WK claims to have solved this one, but there is another in which shows up both for gfortran 4.7. and 6.0.

[Juergen Reuter]

The Heisenbug is not gone for gfortran 6.0. I still get (roughly every third run of the test):

$ ./sindarin_parser.run 
Running script ./sindarin_parser.run
| Writing log to 'sindarin_parser.log'
| ============================================================================
| Running self-test: sindarin_parser
| ----------------------------------------------------------------------------
Running test: sindarin_parser_1 ... success.
Running test: sindarin_parser_2 ... success.
Running test: sindarin_parser_3 ... success.
Running test: sindarin_parser_4
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x11491bef2
#1  0x11491b210
#2  0x7fff822eaf19

[kilian]

So far, all those issues were compiler bugs:

• PACK broken in all gfortran versions
• allocate-on-assignment not yet correct in 4.7
• the combination CLASS argument with allocatable not yet correct in 4.7
• and some regression in 6.0 (wouldn't care about that too much)

Except for the 6.0 bug, all workarounds appear to work.

[Juergen Reuter]

Apparently, that wasn't it. Seems that more or less all cases are still broken.

[Juergen Reuter]

The problem always appears when sindarin_parser%decode tries to push the next parse node. In calling make_pn_decoder, the allocation of the pn_decoder_t runs into the segfault when an expr is supposed to be allocated. One either gets

 allocate expr decoder
+  SEQUENCE    <expr>  =  <atom> <arithmetic_operation>
+  IDENTIFIER  <atom>  = b
+  SEQUENCE    <arithmetic_operation>  =  '*' <integer_literal>
|  +  KEYWORD     '*'  = [keyword] *
|  +  INTEGER     <integer_literal>  = 2
whizard(30308,0x7fff73ced300) malloc: *** mach_vm_map(size=1153774718647537664) failed (error code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug

or a WHIZARD bug for an invalid rule key or so.

[kilian]

Thanks. At least, that's a hint.

[kilian]

I stand corrected - no compiler bug, just a plain ordinary coding error.

The default case of a SELECT CASE was missing, leading to an undefined variable with undefined behavior. Fixed in r6992.