Test failure due to glibc 2.30 and symmetrica

[Timo Kaufmann]

Hi all,

I'm seeing the following test failure:

File "/nix/store/axx7vd9jlxnrrncywdp5jx8g9nc57xkp-sage-src-8.9/src/sage/combinat/sf/classical.py", line 60, in sage.combinat.sf.classical.init
Failed example:
    change({Partition([2,2]):QQ(1)})
Expected:
    s[1, 1, 1, 1] - s[2, 1, 1] + 2*s[2, 2] - s[3, 1] + s[4]
Got:
    s[1, 1, 1, 1] - s[2, 1, 1] + 4214848*s[2, 2] - s[3, 1] + s[4]
**********************************************************************
1 item had failures:
   1 of   8 in sage.combinat.sf.classical.init

git-bisect indicates that our recent update from glibc 2.27 to 2.30 is responsible. The bisect can't pin it down exactly since the update caused some breakage, but it does look like glibc is responsible. The sage function that fails uses symmetrica under the hood. The symmetrica C pacakge seems pretty complicated and sparsely documented, so I wasn't able to reproduce this with a C script.

Has anybody here seen something similar? Are you using glibc 2.30 yet?

Timo

[Michael Orlitzky]

On 3/9/20 8:49 PM, Timo Kaufmann wrote:
> Hi all,
>
> I'm seeing the following test failure:
>
> File
> "/nix/store/axx7vd9jlxnrrncywdp5jx8g9nc57xkp-sage-src-8.9/src/sage/combinat/sf/classical.py",
> line 60, in sage.combinat.sf.classical.init
> Failed example:
>     change({Partition([2,2]):QQ(1)})
> Expected:
>     s[1, 1, 1, 1] - s[2, 1, 1] + 2*s[2, 2] - s[3, 1] + s[4]
> Got:
>     s[1, 1, 1, 1] - s[2, 1, 1] + 4214848*s[2, 2] - s[3, 1] + s[4]
> **********************************************************************
> 1 item had failures:
>    1 of   8 in sage.combinat.sf.classical.init
>
>

That's very similar to

https://trac.sagemath.org/ticket/15312

which turned out to be a memory handling bug in symmetrica. We maintain
a fork of symmetrica now,

https://gitlab.com/sagemath/symmetrica

so if you can reproduce the problem (using one of those short programs
on trac #15312?), it would be a big help. Things look OK with
glibc-2.29, so I'm suspicious of the malloc changes in 2.30.

[Antonio Rojas]

El martes, 10 de marzo de 2020, 1:49:59 (UTC+1), Timo Kaufmann escribió:

Has anybody here seen something similar? Are you using glibc 2.30 yet?

Yes, see https://groups.google.com/forum/#!topic/sage-packaging/hfV2CcyMymE

FWIW, I can no longer reproduce it with glibc 2.31 

[Timo Kaufmann]

Thanks! It turns out that was exactly the issue. For some reason we didn't carry the bruch patch on nix. I probably just added the minimum amount of patches to make the test suite pass since the problem wasn't present at the time. I did check that we were using the same version of symmetrica as sage does though. Apparently the update hasn't happened yet  (#29061).

 

I still can't figure out in which format symmetrica expects its input, so I wasn't able to reproduce it with the C program. The sage test passes with symmetrica 3.0.1 from the fork though.

I think I even stumbled over that ticket when looking into the problem, but didn't read it careful since I assumed it was outdated.

[Timo Kaufmann]

Thanks to you too, seems like we're a bit slow with glibc  and I forgot about that post since it was a couple of months ago. I must've been really inept at googling to miss that. I didn't try it with glibc 2.31, but updating to the fork is probably a good idea nonetheless.

[Dima Pasechnik]

a further example of calling symmetrica from C is on
https://trac.sagemath.org/ticket/28208
(used for a test in its spkg_configure.m4)

> I think I even stumbled over that ticket when looking into the problem, but didn't read it careful since I assumed it was outdated.
>

> --
> You received this message because you are subscribed to the Google Groups "sage-packaging" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-packagin...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-packaging/86c9b83f-3505-41b1-8fab-04b1ab7962e8%40googlegroups.com.

[Timo Kaufmann]

Thanks! That calls a different function though, apparently a much simpler one (since "4" is sufficient input). I can't figure out how to "enter a power sum p_{1^50} with coefficient integer 1". But since the problem is resolved in sage, I don't think a C reproducer would add much value anyway.