rubylang.10.webmeister / spamgourmet.com wrote:
> My config.h for ARMv5 contains both `#define HAVE_LONG_LONG 1` and
> `#define HAVE_UINT64_T 1`, so for all versions of the code it will
> always take the first path. The `unsigned long long` variant as well
> as the `uint64_t` variant seem to be broken on ARMv5, so I decided to
> try the third one (`unsigned long`) by simply removing all other
> alternatives (patch attached). This successfully fixes the problem.

Could be a compiler problem with 64-bit emulation.  Which
compiler/version is this?  Can you try a newer one?
Can you try any other code which uses 64-bit math?

Also, it could be an alignment problem; but I don't see places
where rb_serial_t is not 32-bit aligned...

> I'm not sure why you use the different types in the first place. If it
> works with `unsigned long` (i.e. you do not need more than 32 bits),
> what is the benefit of using `unsigned long long`? If it does bring
> some benefit for other architectures, could you disable its usage at
> least on ARMv5 or check your code whether it makes some assumptions
> about these types that do not hold on ARMv5?

64-bits is needed to avoid overflow on VM state changes.
Otherwise our caches could give false hits and crash.