Is this just a sort of precaution or did bus errors effectively occured?
I've included James Cowgill who saw the problem and made the patch. James, do you have a stacktrace showing a bus error, to narrow down where exactly the code is doing unaligned accesses?
What is strange is that seems to occur only now. CONNECT exists for at least four years and the code of VALBLK was still existing at that time.
Well, MIPS is not a common platform, certainly not for running MariaDB with the CONNECT engine. Most main-stream platforms will not cause a crash for unaligned accesses.
My question is because all (sub)allocations made by connect are always done on a memory whose address is a multiple of 8. This means that in a value block that is aligned on a multiple of 8 location, big integer and doubles should be correctly aligned, integers are aligned on a multiple of 4, smallint of 2 etc.
Is this enough? If not, the patch is required but if it is ok the patch is useless.
Yes, this should be enough, according to my understanding.
However, I don't know how malloc and realloc work on mips processor. These blocks are declared as pointed by a void* pointer. Perhaps this does not make them to make an allocation on a properly aligned memory.
Malloc and friends should always return memory aligned properly for any data type, irrespectively of void* or other pointer declaration.
I checked in CONNECT source, VALBLK blocks are allocated by PlgDBalloc in plgdbutl.cpp line 1206 or PlgDBrealloc line 1268. And indeed, depending on the block size, they can be suballocated or normally allocated by malloc or realloc.
Agree, that looks correct. My understanding from the patch was that CONNECT was storing data packed, eg. two bytes of short followed immediately by 8 bytes of double without padding, or similar. But it sounds from you like this should not be happening in the code. And agree, we should understand exactly how the unaligned access occurs, or what else is the root cause of the errors on MIPS. My guess is that James just saw this during running the test suite on MIPS. It is a bit hard to reproduce without access to MIPS hardware, but maybe qemu can help here. But let's first see if James has a stacktrace that shows exactly where the bus error occurs. - Kristian.