It is testing exceptionally simple code, with exceptionally simple
tests.
I doubt this is a bug in zn_poly.
If it turns out to not be reproducible, I would ignore it. It's much
more likely a cosmic ray or transient hardware fault or bug in the OS.
But let's see if it can be reproduced.
Bill.
O
On 5 April 2011 05:27, William Stein wrote:
> On Mon, Apr 4, 2011 at 5:01 AM, Bill Hart wrote:
>> Is the problem reproducible?
>>
>> If so, a valgrind log would be useful to debug the problem. It should
>> find the source of any segfault. zn_poly would need to be compiled
>> with the -g option to
On Mon, Apr 4, 2011 at 5:01 AM, Bill Hart wrote:
> Is the problem reproducible?
>
> If so, a valgrind log would be useful to debug the problem. It should
> find the source of any segfault. zn_poly would need to be compiled
> with the -g option to GCC. It could of course be a compiler bug.
> Possib
On 04/ 4/11 01:01 PM, Bill Hart wrote:
Is the problem reproducible?
I'll have to check how reproducible it is by building znpoly repeatedly. But
it's the first failure I've known in what must be more than 100 compete builds
of Sage on this machine.
znpoly is only taking 39 s to build and r
Is the problem reproducible?
If so, a valgrind log would be useful to debug the problem. It should
find the source of any segfault. zn_poly would need to be compiled
with the -g option to GCC. It could of course be a compiler bug.
Possibly compilation with a lower optimisation level would make it
