segvs on Travis

[tarcieri]

@namelessjon project moved, and Travis builds can now see libsodium, however there's a segv occuring.

I'm gonna try to dig into this, however perhaps you'll figure it out first?

https://travis-ci.org/cryptosphere/rbnacl/jobs/4273137

[tarcieri]

Well, it's failing in crypto_box_curve25519xsalsa20poly1305_ref_afternm which is getting called here:

https://github.com/cryptosphere/rbnacl/blob/master/lib/rbnacl/boxer.rb#L62

It appears to be blowing up inside the XSalsa20 code, so I'm guessing that's not receiving an appropriately sized buffer.

[namelessjon]

That would be my guess too, but the specs are green here, and the prototype is correct according to the C code. I think it might require poking around in the c code to understand

[tarcieri]

I'm wondering how well NaCl's combined input/output buffers are playing with FFI... I tried loading it up in valgrind but FFI obscures what's actually happening.

This is one of my first experiences debugging an FFI extension and I'm not really sure how to proceed.

[namelessjon]

I can reproduce it here. It fails on my 32-bit netbook, but not the main laptop which is 64-bit. Still no idea how to solve, but at least the debug cycle no longer involves Travis.

[tarcieri]

I'm curious if it's similar to this. NaCl's API is so weird ;)

RubyCrypto/ed25519@00f0fc7

On Mon, Jan 21, 2013 at 12:33 AM, Jon notifications@github.com wrote:

I can reproduce it here. It fails on my 32-bit netbook, but not the main
laptop which is 64-bit. Still no idea how to solve, but at least the debug
cycle no longer involves Travis.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-12488531.

Tony Arcieri

[namelessjon]

No, I don't think so. I'm only changing an int to a long long. If it were a similar thing to that fix I think FFI would still barf on it. I guess my laptop had decided a int was 64-bits, so it didn't matter.