Re: Weird results on a particular ARM platform

[john s. <sk...@us...>]

> 
> We have been successfully using libJudy for a while on a number of different ARM (ARMv7-A - generally ARM Cortex-A9) and x86/x86_64 based platforms but have recently come across an issue when building it for a new ARM based platform (ARMv7-R for an ARM Cortex R4).
> 
> Basically a subsequent call to lookup the Judy array via JLG (after a just previous call to insert into the Judy array via JLI) returns a pointer value offset by two bytes from the pointer returned from JLI.
> 
> Can anyone give any hints on what might be likely causing this / where to start looking to determine the cause?

Ugghh ..

> 
> Is this likely alignment / toolchain / what? I am not sure at all where to start trying to debug it.

I have had problems with Judy on Windows but suspect corruption.
I had to modify Judy to make it work correctly due to improper use
of constants (assumed 1L is size of a pointer which it isn’t on Windows).

The ARM7-A/Cortex R4 is 32 bit right?

I can’t see how it could be an alignment issue since BOTH
addresses are actually returned.

Again I assume the A9 and R4 have the same C integer/pointer model.

So seems there are two answers:

(a) corruption
(b) bug in Judy

So my experience was this: set a value in a Judy1Array.
Retrieve it: woops, its not there. In two separate arrays.
Windows only on Appveyor continuous integration builder only.
On Linux/gcc fine. On OSX/clang fine. On MY Windows box with almost
identical compiler and OS and libraries to Appveyor .. fine.

Is it a bug or corruption??

I regret I do not know the answer.

For the ARM if you have an emulator with debugging you might be able
to trap a modification due to corruption but you’d need to careully build
a memory map of all the Judy Nodes as they’re created to see if anything
clobbers them. Sounds .. more or less impossible unless the bug occurs
on the FIRST insert.

BTW: are you sure its a bug? Judy does opportunistic optimisations.
It can remove things but not clean up the layout until later.
[No idea what that means but it says so in the code :]

This means its possible a get() returns a different value to an insert(),
if the get modifies the array doing an opportunistic optimisation,
though I doubt a non-mutating operation would do that.
I suspect the optiimisation is ONLY internal key fiddling, and doesn’t
move data slots in a JudyLArray so this all seems unlikely to me.

—
john skaller
sk...@us...
http://felix-lang.org