GNU bug report logs - #53696
Integer overflow on Guix GC size calculation

Previous Next

Full log

View this message in rfc822 format

From: Ekaitz Zarraga <ekaitz <at> elenq.tech>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Cc: 53696 <at> debbugs.gnu.org
Subject: bug#53696: Integer overflow on Guix GC size calculation
Date: Wed, 02 Feb 2022 19:51:54 +0000

Hi,

On Wednesday, February 2nd, 2022 at 8:45 PM, Liliana Marie Prikler <liliana.prikler <at> gmail.com> wrote:

> Hi,
>
> Am Dienstag, dem 01.02.2022 um 21:54 +0000 schrieb Ekaitz Zarraga:
>
> > Hi,
> >
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> >
> > On Tuesday, February 1st, 2022 at 10:20 PM, Liliana Marie Prikler
> >
> > liliana.prikler <at> gmail.com wrote:
> >
> > > I find it somewhat concerning that you've accumulated more than
> > >
> > > 2^64 bytes of garbage.
> >
> > I'm a dirty boy.
> >
> > > Are some items counted double here?
> >
> > The number started growing from 0 and then that appeared and it
> > continued smoothly from the previous. It's like something went bad in
> > the middle.
>
> WDYM by the middle? Do you mean the jump back to 0 or do you mean
> something before those lines? If you did encounter a "self-correcting"
> bit-flip that'd be one thing, but to me it appears as though you have
> some very large storage on your hands. Would you mind me asking where
> you purchased that disk 😜

I mean something like:

0
1
2
4
8
10
12
HUGE_NUMBER
HUGE_NUMBER
...
HUGE_NUMBER
15
20
...

It's like it corrected itself. It happened in "low numbers" (less than a
hundred).

I just say this if it helps in the correction. It's very funny, still :3

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.