Segmentation fault if workspace is large

[antoncyrol]

When evaluating runform_complex.frm (files below), I obtain the message

=== Workspace overflow. 40000000 bytes is not enough.

Increasing the workspace leads to

Segmentation fault (core dumped).

This issue occurs with the 4.2.0 pre-compiled binary as well as self-compiled versions of FORM (I tried the newest version and an older one from 2015, the oldest one I was able to compile). However, using the pre-compiled 64-bit binary from Binaries works very well. I tested this with two different Debian-based operating systems.

Commenting out the lines 3383 - 3390 in runform_complex.frm

Repeat;
id PiT(-mom1?,lor1?,lor2?)=PiT(mom1,lor1,lor2);
id PiL(-mom1?,lor1?,lor2?)=PiL(mom1,lor1,lor2);
id PiT(mom1?,lor1?,lor3?)*PiT(mom1?,lor3?,lor2?)=PiT(mom1,lor1,lor2);
id PiL(mom1?,lor1?,lor3?)*PiL(mom1?,lor3?,lor2?)=PiL(mom1,lor1,lor2);
id PiL(mom1?,lor3?,lor2?)*PiT(mom1?,lor1?,lor3?)=0;
id PiL(mom1?,lor1?,lor3?)*PiT(mom1?,lor3?,lor2?)=0;
EndRepeat;

solves the problem in this case. However, since it is executable with FORM 4.1 (and similar files such as runform_simple.frm work very well), I assume this to be a FORM issue. I generated the files with FormTracer. I greatly appreciate any help/ideas/comments!

Thanks and all the best, Anton

Files: WorkSpace.zip

[tueda]

Thanks for your report. Actually this is due to different semantics for "minus vectors" between 4.1 and 4.2. We should have mentioned it as a caveat in the ChangeLog; I will add it.

In FORM 4.2, f(-v?) matches with both f(p) (where v = -p) and f(-p) (v = p). This was needed for us to do pattern matchings like vx(p1?,p2?,Q?)*vx(-p1?,-p2?,-Q?) with vx(p1,-p2,Q)*vx(-p1,p2,-Q), for example. But unfortunately this change with your program

Repeat;
id PiT(-mom1?,lor1?,lor2?)=PiT(mom1,lor1,lor2);
id PiL(-mom1?,lor1?,lor2?)=PiL(mom1,lor1,lor2);
...
EndRepeat;

leads to an infinite loop. If I understand your program correctly, the problematic id statements are expected to run once at most, so you can move them outside the repeat-loop:

id PiT(-mom1?,lor1?,lor2?)=PiT(mom1,lor1,lor2);
id PiL(-mom1?,lor1?,lor2?)=PiL(mom1,lor1,lor2);
Repeat;
...
EndRepeat;

Or, another solution would be to put a restriction vector_ (available in 4.2) as

Repeat;
id PiT(-mom1?vector_,lor1?,lor2?)=PiT(mom1,lor1,lor2);
id PiL(-mom1?vector_,lor1?,lor2?)=PiL(mom1,lor1,lor2);
...
EndRepeat;

to tell FORM that mom1 is a vector without a minus.

[antoncyrol]

Very good! I actually prefer the behavior of 4.2 :-)

(Unimportant) details: You understand it correctly, the problematic statements should only be applied once. Their only purpose is to eliminate the minus sign (PiT and PiL are projection operators and thus quadratic in their first arguments). Hence, pulling them out of the repeat statement solves the problem. However, I chose another solution for (internal) technical reasons:

Repeat;
id PiT(mom1?,lor1?,lor2?)*PiT(mom1?,lor2?,lor3?)=PiT(mom1,lor1,lor3);
id PiT(-mom1?,lor1?,lor2?)*PiT(mom1?,lor3?,lor1?)=PiT(mom1,lor3,lor2);
and similar ...
EndRepeat;

I don't know which one is better/faster but this is not relevant in this case. Thanks again.