Recurrent segmentation fault error #3339
Comments
|
A wild guess: Note: We did have some more or less random GC corruption errors in our CI, see #3184 for details. And these should be fixed in 1.10.1. |
|
@StevellM Now that Julia 1.10.1 has been released, definitely upgrade to it and let us know if the issue still occurs. |
|
Sorry it took me some time to react. Thank you for both your suggestions: I am working on a server on which I could not apply any of the two things you have told me. This morning I have asked to have Julia updated. I will re-run the buggy computations now and see whether it still breaks. |
|
Update: while it was crashing after few of my cases (3 to 5) in julia 1.10.0, in julia 1.10.1 it keeps running even after the 26th case. In summary: problem solved! |
Describe the bug
Some code I run tends to be long while computing double cosets, and very often they just crash. Here are some information about a kind of double cosets I might try to compute in my use cases:
Double cosets:$H\setminus G/K$ , where $H, G, K$ are $\mathbb{F}_2$ vector spaces.
$|G| = 51231497335603200$
$|H| = 393216$
$|K| = 490497638400$
I tried to speed up the computations by finding a permutation group isomorphic to$G$ , and such a permutation group has degree 4094 in that case.
Before these double cosets computations, I usually have some other group operations like stabilizers computations, restrictions of automorphisms, creation of homomorphisms and computation of their images. It can happen also that computing these double cosets take a certain amount of time when computed alone, but embedded inside the whole process, the computation time (for the double cosets) can be much more larger (currently by a factor 4, waiting to see if it terminates)!
If I run my code on several examples in a row, and even sometimes on one example, I get this kind of errors:
Important note: I did the exact same computations last year and I never had such a problem before. Sometimes double cosets computations were long, but I never had any segmentation fault, while now for the same computations, it is a recurrent issue. It might be that the reason is due to another function, or an accumulation of GAP calls, which then makes garbage collection unhappy.
To Reproduce
Here is the only way I found to give an example which does not always work (quite long code). However the segmentation fault is not always "there", so this example is not always bugging. See the context comment at the end of the issue for why I struggle to provide a useful example.
Expected behavior
I would expect that if I run the same procedure several times on different data, then everything should go smoothly. Here the point is that it looks cumulative, and the segmentation fault is a bit random. On the same set of 20 data, it could bug after the 3rd one, or after the 15th, or never. At least, if there is a bug, I would expect it to happen always at the same time.
Also, the bug seems to be more recurrent when I do the double cosets computation in a sequence of GAP calls (so after some image/kernel/stabilizer computations). When done alone, it takes time but terminates.
System (please complete the following information):
Please paste the output of
Oscar.versioninfo(full=true)below. If this doesnot work, please paste the output of Julia's
versioninfo()and your Oscarversion.
Additional context
The computations are done with external codes on a local branch. The reasons are that the fixes I need are not yet available in Oscar, I need to use Magma in parallel. However, this does not seem to be somewhere related to the issue I guess. The computations are quite heavy so I cannot really give a mre. But my code, branch and data could be shared via git and Oscar serialization if someone wants to try to investigate further on my particular set of data.
The text was updated successfully, but these errors were encountered: