Repository navigation
Unexpected code in ReNumber #211
Description
Hello,
I was writing a small script to see to what extent I could increase the test coverage in sort.c and compress.c. I have something like the following:
#-
#: TermsInSmall 128
#: LargePatches 16
#: FilePatches 4
*#: SubTermsInSmall 64
#: SubLargePatches 8
#: SubFilePatches 2
Off Statistics;
CFunction f,g;
Symbol x,y;
* 128*16=2048 terms cause a sort of the large buffer to disk.
* multiples of 2048*4=8192 terms cause a stage 4 sort
#define NTERMS "40001"
#define ARGNTERMS "2001"
Local test1 = <f(1)>+...+<f(`NTERMS')>;
Local test2 = g(<f(1)>+...+<f(`ARGNTERMS')>);
.sort
* Cancel all terms, but keep distance so that most terms only cancel in the final sort
Identify f(x?) = f(x) - f(`NTERMS'-x+1);
Argument g;
Identify f(x?) = f(x) - f(`ARGNTERMS'-x+1);
EndArgument;
Print +s;
.end
If one uncomments the #: SubTermsInSmall 64 setting, tform crashes with Unexpected code in ReNumber. form does not crash, but test2 contains many f(...) terms that are not inside g.
Thanks,
Josh
Activity
jodavies commentedon Jun 30, 2017
tueda commentedon Jun 30, 2017
It must be an old bug. I got many f's with FORM 4.1 (Oct 25 2013).
vermaseren commentedon Jun 30, 2017
jodavies commentedon Jun 30, 2017
Great, that seems to work.
Now, if I add to the first module:
and to the second module:
form has no problems, but tform -w4 crashes about 60% of the time, with various errors:
EDIT: For this, at some point before the crash, valgrind gives
tueda commentedon Jul 1, 2017
Running
valgrind tvorm -w2forgives me
Now 100% it occurs (though it is not in a worker).
vermaseren commentedon Jul 1, 2017
tueda commentedon Jul 1, 2017
The minimum seems to be 129 terms,
but unfortunately it doesn't crash in spite of the memory bug.
tueda commentedon Jul 1, 2017
Two things:
MaxTermSizeaffects on the appearance of the error (similar to gzip errors #95).In the following log, is
file->POsizeoffile->handle=4OK??The corresponding
vormlog:tueda commentedon Jul 3, 2017
The first example causes memory leaks: https://travis-ci.org/tueda/form/jobs/249641044#L4542. (Should we reopen the issue?)
vermaseren commentedon Jul 3, 2017
tueda commentedon Jul 3, 2017
Here is another spam of valgrind log (vorm) with increasing
SortIOSize:It is very strange that
PutIn()is called withfile->POsize=10000000, i.e.,SortIOSize. ThenReadFile()overflows from the buffer allocated byAllocSortfor the function argument (only 5100488 bytes, valgrind says). GDB shows it is allocated withAllocSort (LargeSize=4000000, SmallSize=500000, SmallEsize=800000, TermsInSmall=16, MaxPatches=1, MaxFpatches=4, IOsize=32768). For TFORM, instead ofSortIOSize, the value calculated fromAM.S0->file.POsizeis used (see threads.c:541).vermaseren commentedon Jul 3, 2017
tueda commentedon Jul 3, 2017
Actually, the problematic
PutIn()is called withAR.FoStage4[0]:24 remaining items
vermaseren commentedon Apr 8, 2024
ahamaline commentedon Apr 8, 2024
vermaseren commentedon Apr 8, 2024
ahamaline commentedon Apr 8, 2024
OK, I'm running it now with the first of those options.
ahamaline commentedon Apr 8, 2024
So I got to the printout but not yet to the crash. Here is an example term: outside the brackets we have
tenredgg[mu1,mu2], and within the brackets one of the terms is2/( - 1 + D)*Etens[p2,mu2]* Etens[p2,nu97]*Etens[p1,mu1]*Etens[p1,nu99]*Mom[p2,nu2]*Mom[p1,nu1]^2 *Mom[p1,nu2]*Mom[p1,nu97]*Mom[p1,nu99]*Mom[p1,mudotp1]^2*Mom[p1, mudotp2]^2*prop[k1,0]^4*den[4,2]*(k1.k1)^2*sSS^10*D*kappa^2*mh^(-6)Of course the more problematic terms are those where tenredgg has many indices, but I can't seem to scroll far enough to get to those... The idea should be the same; each index appears exactly twice in either tenredgg, Mom, or Evect. There are always 4 powers of Evect but the powers of Mom vary.
'Mom[p2,nu2]' is really just a way to write p2[nu2], chosen specifically to avoid having the vector contract automatically.
ahamaline commentedon Apr 9, 2024
Ok, I found an example term with sixteen indices in tenredgg (in the printout before the module):
tenredgg[mu1,mu2,mu4,nu1,nu99,mudotp1,mudotp2,mudotp3,mudotp4,mudotp5 ,mudotp6,mudotp7,mudotp8,mudotp9,mudotp10,mudotp11] * ( 16384/( - 1 + D) /( - 1 + D)*Etens[p2,mu2]*Etens[p2,mu4]*Etens[p1,mu1]*Etens[p1,nu99]* Mom[p1,nu1]*Mom[p1,mudotp1]*Mom[p1,mudotp2]*Mom[p1,mudotp3]*Mom[p1, mudotp4]*Mom[p1,mudotp5]*Mom[p1,mudotp6]*Mom[p1,mudotp7]*Mom[p1, mudotp8]*Mom[p1,mudotp9]*Mom[p1,mudotp10]*Mom[p1,mudotp11]*prop[k1,0] ^13*den[92897280,169906176]*(k1.k1)^11*sSS^12*kappa^2*mh^(-8) +...)The code has been running for 17.5 hours now and has neither crashed nor finished the module.
jodavies commentedon Apr 9, 2024
If you resolve the
Mominto actual scalar products where you have repeated indices you will get a much smaller result, but I don't know what the rest of your code does and it is not really relevant to the fact that you got the crash.I imagine this is not going to be easily reproducible. Possibly with a larger portion of your input expression and artificially small buffer settings or something like that.
Do you have the log file from the crashed run?
vermaseren commentedon Apr 9, 2024
ahamaline commentedon Apr 9, 2024
Yes, I agree that the code is absurdly inefficient for my use case. I did not write it and I don't understand the reasons for the authors' choices, so changing things is scary, but it looks like the savings would be worthwhile. The large number of terms is mainly due to the combinatorial explosion of index configurations, which would be avoided if we used either vectors or dummy indices.
I did not save the log file; it did not have much that seemed informative. Just 56,000 StageSort reports from the various threads, followed by the error.
Thank you for the tip about avoiding denominators. But how could the denominator be related to a crash that occurs in the
dd_replacement?I will add that the error must not be deterministic, since this run has already continued for many more StageSorts than the one that crashed.
jodavies commentedon Jul 17, 2026
I don't know what the status of this one is these days. Related issues were fixed and referenced in #468
teoretik32 commentedon Oct 22, 2026
We observed a TFORM-specific failure while processing a large symbolic expression.
Banner:
TFORM 5.0.1 (Jun 24 2026, v5.0.1), command:tform -q -w10 g0828.frm.The module where it stops ends with
.sort:split-Vh3-Ch3;(physical line 561); its only statements are two simple substitutions,id Vh3=-l1;andid Ch3=+Kap2;. Elapsed time 8:11, peak RSS 4,719,600 KiB, exit status 1. There was ample free RAM and no OOM event. The input has 1,127 lines plus includes;PolyRatFunis disabled in this module.Sequential FORM 5.0.1 completes the same programs successfully (3.5–6 hours each). Nine distinct heavy jobs failed under
-w10in the same way (some with signal errors instead of this message); only this original crash log survives.Could this be related to #211 / #911, or should we file a separate issue with a reduced reproducer? We can try to produce one if useful.
jodavies commentedon Oct 22, 2026
Presumably the patch of #911 does not help here, since you did not receive the
Currently Stage 4 sorts are not allowed for function arguments or $ variablestermination anyway.Are you able to share your code (privately by email if you prefer) so that I can try to reproduce the crash locally?
teoretik32 commentedon Oct 22, 2026
Thank you for looking into it. Unfortunately I cannot share the program as is: it includes a private set of model files (the Feynman rules of an unpublished calculation). I am preparing a reduced reproducer instead: the intermediate expression is written with Save right before the failing module, so the test program becomes Load + the two substitutions + the .sort. I will also check how deterministic the crash is (how many runs out of N fail with -w10, and what happens with -w2 and -w4). I will post it here within a day or two; if the saved expression turns out too large for an attachment, I will send a download link or e-mail it, whichever you prefer.
teoretik32 commentedon Oct 23, 2026
@jodavies Thank you for looking into this. I have attached a self-contained, anonymised test package for the intermittent TFORM 5.0.1 “Unexpected code in ReNumber” crash reported above.
The archive contains:
repro_anon.frm: declarations, loading of an intermediate snapshot, and the original modules up to and including the failing one, with user-defined names consistently renamed;snapA.sav.gz: a snapshot written by sequential FORM 5.0.1, which decompresses to about 113 MB;run.sh, checksums, and a README documenting the platform, expression sizes, and all 13 subsequent reproduction attempts.Run
./run.sh 10fortform -q -w10, or./run.sh seqfor sequential FORM. The threaded run takes about 7–8 minutes and requires approximately 5 GB RAM and 15 GB scratch space on my machine; the sequential run takes about 30 minutes.Current reproducibility status: the original crash occurred in a module containing only two
idsubstitutions followed by.sort, with three input expressions of 38,639,096 terms each. During the same night, 9 of 19 heavy programs in the same family failed while two TFORM jobs were running concurrently. All nine complete successfully with sequential FORM.However, none of the 13 subsequent attempts with the original program or reduced variants reproduced the crash, including runs with different worker counts. This package therefore provides a reduced test case, but does not currently trigger the failure reliably. We have not yet tested whether CPU or disk contention affects reproducibility.
Larger snapshots taken immediately before the failing module (3.0 GB and 3.9 GB) are also available if useful. I would be happy to run further tests, including repeated runs or concurrent jobs; please let me know what diagnostics you would like collected.
tform_renumber_repro_anon_20261022.tar.gz
tueda commentedon Oct 26, 2026
FYI: I ran
run.shwithout any arguments (which runstform -q -w10) 600 times on a Linux machine using TFORM built from the currentmasterbranch (which is indeed the same as v5.0.2). No errors occurred in any of the 600 runs.