memory corruption issues in WHIZARD 1

[Christian Speckner]

Analyse corruption of WHIZARD 1 structures using compiler options and the valgrind.

[Christian Speckner]

You might want to look at the patches that I checked into my 1.93_fix_corruption branch. These address a couple of memory corruption issues that can be found via compiler switches (or valgrind). However, they are just workarounds which don't really fix the issues.

[Christian Speckner]

OK, reset :) I've restarted working on this from the 1.xx branch. Two of my previous fixes already have been included by JR, comprising of

• A bounds violation in init_beam_polarization caused by the dimensionality of rho_hel vs. rho_vector
• A bounds violation when writing HEPEVT output (with an spurious field written in the output).

r1826 fixes another bounds violation in vamp_apply_equivalences - the previous code assumed the same grid size for all channels, not only for those connected by an equivalence. Actually, this is funny as the absence of this issue in W2 reveals another bug there: it seems the equivalences are not applied there correctly, and the broken code never gets called :) I'll open a separate ticked for this...

Now, only two issues remain on my list:

• A bounds violation in guess_color_flow
• Dito in whizard_event.

[Christian Speckner]

The issue in whizard_events is fixed in r1827. mc_process_index is frequently looped over from 1 to mc_number_prcesses, leaving it set to mc_number_processes + 1. Workaround by setting it to mc_number_processes after every such loop.

[Christian Speckner]

The guess_color_flow issue is fixed in r1828. For some reason, col_flow and acl_flow were created with the second index going from 1 to n_flv_out, while guess_color_flow iterated from 1 to n_flv (which makes perfect sense for me), so I am now allocating them as 1:n_flv. Of course, it may be that I just don't understand the logic behind the algorithm, but as the color flow information in event files is known to be broken for flavor sums anyway, I guess no big harm is going to come out of this fix.

What remains are some complaints from valgrind about "jump or move depending on uninitialized memory", but I have a feeling of this being linked to the way gfortran implements the passing of optional parameters. In any case, unless anyone complains about unpredictable, gross misbehavior of WHIZARD (which hasn't happened so far), this is probably fine and not worth the pain of hunting it down.

[Christian Speckner]

OK, I've run a bunch of checks both with 1.93 and the current 1.xx trunk; apart from some segfaults with 1.93, both version behave similarly for me - closing the ticked.

[Juergen Reuter]

Milestone v1.94 deleted