<arigato>
thanks! the first remark is that many other tests fail differently
<mattip>
is the chroot reporting a 64 bit cpu?
<arigato>
yes, but in most places we use "sys.maxint > 2**32" as the real test
<arigato>
exceptions would be in jit/backend
<mattip>
how is this stretch (debian) chroot different from the previous xenial (ubuntu) chroot?
<arigato>
I don't know
<mattip>
it has gcc 6 instead of 5
<arigato>
I would go for debugging the actual failures
<arigato>
in pdb
<mattip>
ok
* mattip
off for dinner, will try later
<arigato>
e.g. the SignedLongLong issues, with pdb we can learn at least which function contains the wrong combination of types
i9zO5AP has quit [Quit: WeeChat 2.3]
Ai9zO5AP has joined #pypy
Zaab1t has quit [Quit: bye bye friends]
<mattip>
it is in the graph of ArenaCollection.allocate_new_arena
<mattip>
the op that raises is v898 = cast_adr_to_int(v897, ('emulated')
<mattip>
)
<arigato>
maybe the address happens to be a pointer located in the upper half of the 32-bit address space, and our emulation of cast_adr_to_int('emulated') returns an unsigned number
<arigato>
which is not a Signed
<arigato>
check opimpl.py or maybe llinterp.py for cast_adr_to_int
<mattip>
lltypesystem/llmemory.cast_adr_to_int has a 'emulated' mode
<arigato>
check all implementations of _cast_adr_to_int
<arigato>
for example, the one in llarena.py
<arigato>
returns something based on the array module's buffer_info() method
<arigato>
maybe that can return an unsigned number too large for 31 bits
<mattip>
good guess. On stretch32, array.array('i', [10]).buffer_info() returns (4171952592L, 1)
<mattip>
on xenial32, (153574416, 1)
<arigato>
OK
<arigato>
then, take that number and use number = rffi.cast(lltype.Signed, number)
<arigato>
or do that on the final "number + self.offset" value
* mattip
comparing the python headers for configuration differences
<arigato>
that's unlikely to be there
<arigato>
it's more a system difference where malloc() tends to return number in 0 < m < 2**31
<arigato>
or not
<arigato>
my guess is that, so far, we've only tested linux32 systems where m tended to be naturally below 2**31
<arigato>
rlib.rvmprof.test.test_rvmprof should not run at all: rvmprof is only supposed to support 64-bit
zzarr has quit [Ping timeout: 246 seconds]
<mattip>
I don't know how much time I want to put into 32 bit linux, but it is annoying
<mattip>
that it doesn't work out of the box
<mattip>
(nothing against the work that has been done, just frustrated by trying to set this up)