Gob crashes on slice of nil valied *big.Ints

[Péter Szilágyi]

Hi,

  There seems to be a bug in the gob encoder where it would crash given a slice of pointers to big.Ints, and the pointers being empty: here's the code to reproduce it: http://play.golang.org/p/pz_E3cQ0_j

If I encode a nil *big.Int, it works.

If I encode a slice of *string-s, each nil, it works.

If I encode a slice of *big.Int-s, it panics.

  Am I the one who's doing something wrong?

Cheers,

 Peter

[Jan Mercl]

On Wed, Apr 17, 2013 at 2:12 PM, Péter Szilágyi <pet...@gmail.com> wrote:
> Am I the one who's doing something wrong?

Not sure who's fault, but I think here is the panic source:
http://golang.org/src/pkg/math/big/int.go?s=21391:21407#L875

-j

[Nate Finch]

The line above, I think. Code looks the same on tip, and fails similarly on tip.

[Jan Mercl]

On Wed, Apr 17, 2013 at 2:28 PM, Nate Finch <nate....@gmail.com> wrote:
> The line above, I think. Code looks the same on tip, and fails similarly on
> tip.

You're right: http://golang.org/src/pkg/math/big/int.go?s=21335:21340#L873

-j

[Péter Szilágyi]

I think the problem lies elsewhere, since encoding an array of nil valued string pointer works.

On Wed, Apr 17, 2013 at 2:35 PM, Dan Kortschak <dan.ko...@adelaide.edu.au> wrote:

The issue seems to be that encodeArray doesn't check whether the
elements of an array/slice are zero (it does check whether the
array/slice is zero and a single item). This is gobEncodeOpFor:

http://golang.org/src/pkg/encoding/gob/encode.go#L634

[Jan Mercl]

On Wed, Apr 17, 2013 at 2:38 PM, Péter Szilágyi <pet...@gmail.com> wrote:
> I think the problem lies elsewhere, since encoding an array of nil valued
> string pointer works.

String pointers are quite uncommon. Can you please share the snippet?

-j

[Jan Mercl]

On Wed, Apr 17, 2013 at 2:55 PM, Péter Szilágyi <pet...@gmail.com> wrote:
> If was the second case in my example code I've provided when opening the
> thread, just to show that slices of lost of nil-s work. It wasn't meant as a
> practical use case, just demo.

Ah, thank you. I think meanwhile Dan nailed it.

-j

[Péter Szilágyi]

Yes, I was checking it too. Haven't figured it all out yet (so forgive my ignorance), but zero value pointers aren't checked in the encString method either, which is the encOp for strings. So why does that work?

[Matt Kane's Brain]

Nil-values string pointers won't call big.Int.GobEncode though, and that's where the problem lies.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
matt kane's brain
twitter: the_real_mkb / nynexrepublic
http://hydrogenproject.com

[Dan Kortschak]

The spam filter seems to have been a little over zealous in this thread.

[Péter Szilágyi]

If was the second case in my example code I've provided when opening the thread, just to show that slices of lost of nil-s work. It wasn't meant as a practical use case, just demo.

[Péter Szilágyi]

Filed an issue: https://code.google.com/p/go/issues/detail?id=5305

[Dan Kortschak]

You expect *string to work since it is not self encoding. The panic
comes when a GobEncoder type is not detected as being zero for its
concrete type and the GobEncode method is called.

[Dan Kortschak]