Panicked at 'arithmetic operation overflowed'

[hrektts]

I encountered the following error when I ran the program shown in here.
The program is compiled on a host machine, which is x86_64-linux, for a powerpc-linux target machine.
This error doesn't occur when the same program is build and run on x86_64-linux.

Any idea?

Error on a powerpc-linux target machine:

thread '<main>' panicked at 'arithmetic operation overflowed', /home/dev/src/rust/src/libcore/hash/sip.rs:132

and backtrace:

stack backtrace:
   1: 0x202186cb - sys::backtrace::write::hc5626c9e3e0501c9bhs
   2: 0x2021bf73 - panicking::on_panic::h96b5dcfa293f235fkXw
   3: 0x202020e7 - rt::unwind::begin_unwind_inner::hf20ebac6e3946e66uCw
   4: 0x20202263 - rt::unwind::begin_unwind_fmt::h9e7625955282a32cABw
   5: 0x2021b893 - rust_begin_unwind
   6: 0x20255567 - panicking::panic_fmt::had30524245a9e2c9EJy
   7: 0x2025552b - panicking::panic::ha2c639b2e7b39d75bIy
   8: 0x201fbe07 - hash::sip::SipHasher::write::h7635dfd3dbc8a7ccAVG
                at /home/dev/src/rust/src/libcore/hash/sip.rs:132
   9: 0x201fbc93 - hash::sip::SipHasher.Hasher::write::h94c8a32a653d4fde3bH
                at /home/dev/src/rust/src/libcore/hash/sip.rs:175
  10: 0x201fbc1b - hash::Hasher::write_u32::h3033101901876172782
                at /home/dev/src/rust/src/libcore/hash/mod.rs:125
  11: 0x201fbba7 - hash::impls::u32.Hash::hash::h69350134608348974
                at /home/dev/src/rust/src/libcore/hash/mod.rs:190
  12: 0x201fbb3f - Person...std..hash..Hash::hash::h9556475301775050917
                at src/main.rs:5
  13: 0x201fb8a3 - my_hash::h11966543868887286583
                at src/main.rs:14
  14: 0x201f82e7 - main::hd517835c7e164da5Aba
                at src/main.rs:22
  15: 0x2021ded3 - rt::unwind::try::try_fn::h677838005097809313
  16: 0x20220be7 - rust_try_inner
  17: 0x20220bb3 - rust_try
  18: 0x2021daeb - rt::lang_start::hff0e75f58cd428aePRw
  19: 0x202003eb - main
  20: 0x1ffb6703 - <unknown>

Additional info of host machine:

$ uname -a
Linux ... 3.13.0-52-generic #86-Ubuntu SMP Mon May 4 04:32:59 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

$ rustc -V --verbose
rustc 1.1.0-dev (05d5fcaa5 2015-05-07) (built 2015-05-07)
binary: rustc
commit-hash: 05d5fcaa5ba0c385e1dc97037c89fae437634fc3
commit-date: 2015-05-07
build-date: 2015-05-07
host: x86_64-unknown-linux-gnu
release: 1.1.0-dev

$ cargo -V --verbose
cargo 0.2.0 (ece2a92 2015-05-06) (built 2015-05-07)

Additional info of target machine:

$ uname -a
Linux ... 2.6.30.3 #34 Tue Dec 17 09:52:34 PST 2013 ppc GNU/Linux

[pnkfelix]

Is this a 64-bit PowerPC target, or a 32-bit one? (I cannot immediately tell from the target's uname -a output...)

[hrektts]

It's 32-bit. (It's definitely confusing...)

[pnkfelix]

Okay. I'm betting we can reproduce this if we cross compile from a 64-bit target to any 32-bit one; namely cross-compiling from x86_64 to i686 (or whatever it is called). I'll look into trying that when I get a chance.

[hrektts]

I’d appreciate it. I'd like to share my cross-compiling environment on here in case I miss something.
I built my toolchain on Docker, and rustc & cargo were compiled on the highlighted part.

[steveklabnik]

Triage: I bet https://github.com/japaric/cross would make this easy to reproduce; I can't do it at the moment though.

[jonas-schievink]

~/repro *master> cross build
fish: “cross build” terminated by signal SIGSEGV (Address boundary error)

For some definition of easy, I guess 😂

[steveklabnik]

Triage: are you still seeing this problem? Can anyone reproduce?

[hrektts]

Sorry for late reply.
The error has been cleared with rustc 1.29.0. However, calculated hash values are different between powerpc (big endian) and x86_64 (little endian). Is it OK? The values are follows:

$ cargo run --target x86_64-unknown-linux-gnu                                                                                                                                                              
    Finished dev [unoptimized + debuginfo] target(s) in 1.32s
     Running `target/x86_64-unknown-linux-gnu/debug/hash-test`
10274620341943426671
16828784525031417047

$ cross run --target powerpc-unknown-linux-gnu
    Finished dev [unoptimized + debuginfo] target(s) in 0.07s                                                                                                                                                                                 
     Running `qemu-ppc /target/powerpc-unknown-linux-gnu/debug/hash-test`
12793483990194865043
15425382868227043520

[ishitatsuyuki]

@hrektts Hashes are only guaranteed to be same inside the same process.

It's obviously different between architectures, and it's even allowed to vary between different execution (though I don't know if we implement such randomisation).

[hrektts]

@ishitatsuyuki Ah, I misunderstood about it. I thought that it was something like the git commit hash. Thanks for your comment.

Since there is no error anymore, I will close this.