Re: [Maria-developers] Patch for unaligned word access in CONNECT storage engine

2016-10-28 Thread Kristian Nielsen 

>>> 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.

___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-developers] Patch for unaligned word access in CONNECT storage engine

2016-10-25 Thread Sergei Golubchik 
Hi, Kristian!

On Oct 22, Sergei Golubchik wrote:
> Hi, Kristian!
> 
> Yes, it is maintained, I've forwarded your email to the maintainer.

And that's the reply I got:

=

Hi, Sergei,

Le 23/10/2016 à 00:32, Sergei Golubchik a écrit :

> Hi, Olivier!
> On Oct 23, Olivier Bertrand wrote:

>> Hi Sergei,
>>
>> Is this just a sort of precaution or did bus errors effectively occured?

> I cannot say for sure, I've just forwarded an email from the
> maria-developers@ mailing list. And in that email Kristian Nielsen
> forwarded a patch that Debian applies to Connect engine...
> 
> But I'm almost certain that the bus error did occur. First, because
> Debian packages only fix issues that fail in Debian - on the test
> machines or as reported by users. They don't do precautions.
> And second, because this kind of crash is farily common on some
> architectures.

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.

This is why I'd like to know exactly when crashes occur and under what
circumstances.

>> 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.
>
> Apparently, there were crashes, the email mentions
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838914 and the bug
> report talks about crashes on MIPS.

>> Also, if the patch is required, because it can have a performance
>> impact when dealing with big tables, it should be made conditional
>> and applied only when necassary. Something like:
>>
>> #if !patch_requied
>> #define UnalignedRead(N)  Typp[N]
>> #define UnalignedWrite(N,V) Typp[N] = V
>> #endif
>> 
>> Remains to find how to set the patch_required variable.
>
> Three thoughts here.
> 
> 1. first, I'd check the assembly on x86 - it's a memcpy with a constant
>and small (2-4-8 bytes) size. There's a good chance that a compiler can
>optimize it.
> 
> 2. if you say that all memory accesses should be aligned, you can add
>asserts to these UnalignedRead/UnalignedWrite macros - perhaps
>the access is unintentionally unaligned somewhere and you might want
>to fix it?

Here we go to the interesting part. Firstly I checked out what were
the rules of alignment
in mips (and risc?) processor and, according to a web site, it seems
to be:

  Alignment is important for a MIPS processor, it only likes to read
  multi-byte values from memory at an address that's a multiple of
  the data size.

This means that a memory block that will contain an array of
multi-byte values must be aligned at an address multiple of the byte
number.

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.

As I said, if they are suballocated there should be no problem (except
the entire sarea is not aligned but this would cause unalignment errors
for all suballocations)

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.

In any case, this is the place to check and, if a patch is necessary,
this is the place to place it.  Note that it would be usefull for all
processors because even if no crash occur, wrongly aligned blocks will
cause a performance penalty, chiefly because they are big blocks.

In any case, the proposed patch is inappropriate and should not be done.

However, if we discover that malloc always returns a memory address that
is a mutiple of eight, this shows that the problem is elsewhere and
would show that the proposed patch is useless.

Regards, Olivier

> 3. And, the last - you use use __mips__ for your patch_required to
>detect MIPS and add further architectures later in a similar way, if the
>need arises.

>Le 22/10/2016 à 12:28, Sergei Golubchik a écrit :
>> Bonjour, Olivier
>>
>> This is just FYI, in case you didn't see the email below
>> (I don't know if you're on that mailing list)
>>
>> Regards,
>> Sergei
>> Chief Architect MariaDB
>> and secur...@mariadb.org
>>
>> - Forwarded message from Kristian Nielsen <kniel...@knielsen-hq.org> 
>> -
>>
>> Sender: Maria-dev

Re: [Maria-developers] Patch for unaligned word access in CONNECT storage engine

2016-10-22 Thread Sergei Golubchik 
Hi, Kristian!

Yes, it is maintained, I've forwarded your email to the maintainer.

On Oct 21, Kristian Nielsen wrote:
> Sender: Maria-developers
>  <maria-developers-bounces+serg=mariadb@lists.launchpad.net>
> From: Kristian Nielsen <kniel...@knielsen-hq.org>
> To: MariaDB Developers <maria-developers@lists.launchpad.net>
> Subject: [Maria-developers] Patch for unaligned word access in CONNECT
>  storage engine
> Date: Fri, 21 Oct 2016 23:16:45 +0200
> List-Archive: <http://lists.launchpad.net/maria-developers>
> 
> Who should be contacted about issues in the CONNECT storage engine?
> 
> The attached patch is from Debian Bug#838914
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838914
> 
> Apparently the code does direct unaligned accesses of word data. This works
> fine on the x86 architecture, but on some other architectures (like MIPS),
> it causes a bus error.
> 
> In other places in the server code, the similar issue is handled correctly
> with uint4korr() and similar macros (though these also deal with byte
> order).
> 
> I think the patch (or something similar) is good and should be
> upstreamed. But I am not sure how the CONNECT storage engine is maintained -
> should this go directly into MariaDB? If there is an upstream maintained
> CONNECT storage engine, probably it should preferably go there first?
> 
>  - Kristian.g
> 
Regards,
Sergei
Chief Architect MariaDB
and secur...@mariadb.org

___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp

[Maria-developers] Patch for unaligned word access in CONNECT storage engine

2016-10-21 Thread Kristian Nielsen 
Who should be contacted about issues in the CONNECT storage engine?

The attached patch is from Debian Bug#838914

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838914

Apparently the code does direct unaligned accesses of word data. This works
fine on the x86 architecture, but on some other architectures (like MIPS),
it causes a bus error.

In other places in the server code, the similar issue is handled correctly
with uint4korr() and similar macros (though these also deal with byte
order).

I think the patch (or something similar) is good and should be
upstreamed. But I am not sure how the CONNECT storage engine is maintained -
should this go directly into MariaDB? If there is an upstream maintained
CONNECT storage engine, probably it should preferably go there first?

 - Kristian.g

Description: Handle unaligned buffers in connect's TYPBLK class
 On MIPS platforms (and probably others) unaligned memory access results in a
 bus error. In the connect storage engine, block data for some data formats is
 stored packed in memory and the TYPBLK class is used to read values from it.
 Since TYPBLK does not have special handling for this packed memory, it can
 quite easily result in unaligned memory accesses.
 .
 The simple way to fix this is to perform all accesses to the main buffer
 through memcpy. With GCC and optimizations turned on, this call to memcpy is
 completely optimized away on architectures where unaligned accesses are ok
 (like x86).
Author: James Cowgill 
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
Index: mariadb-10.0-10.0.27/storage/connect/valblk.h
===
--- mariadb-10.0-10.0.27.orig/storage/connect/valblk.h
+++ mariadb-10.0-10.0.27/storage/connect/valblk.h
@@ -139,6 +139,7 @@ class VALBLK : public BLOCK {
   int Prec; // Precision of float values
   }; // end of class VALBLK
 
+
 /***/
 /*  Class TYPBLK: represents a block of typed values.  */
 /***/
@@ -151,40 +152,40 @@ class TYPBLK : public VALBLK {
   // Implementation
   virtual bool   Init(PGLOBAL g, bool check);
   virtual intGetVlen(void) {return sizeof(TYPE);}
-  virtual char   GetTinyValue(int n) {return (char)Typp[n];}
-  virtual uchar  GetUTinyValue(int n) {return (uchar)Typp[n];}
-  virtual short  GetShortValue(int n) {return (short)Typp[n];}
-  virtual ushort GetUShortValue(int n) {return (ushort)Typp[n];}
-  virtual intGetIntValue(int n) {return (int)Typp[n];}
-  virtual uint   GetUIntValue(int n) {return (uint)Typp[n];}
-  virtual longlong GetBigintValue(int n) {return (longlong)Typp[n];}
-  virtual ulonglong GetUBigintValue(int n) {return (ulonglong)Typp[n];}
-  virtual double GetFloatValue(int n) {return (double)Typp[n];}
+  virtual char   GetTinyValue(int n) {return (char)UnalignedRead(n);}
+  virtual uchar  GetUTinyValue(int n) {return (uchar)UnalignedRead(n);}
+  virtual short  GetShortValue(int n) {return (short)UnalignedRead(n);}
+  virtual ushort GetUShortValue(int n) {return (ushort)UnalignedRead(n);}
+  virtual intGetIntValue(int n) {return (int)UnalignedRead(n);}
+  virtual uint   GetUIntValue(int n) {return (uint)UnalignedRead(n);}
+  virtual longlong GetBigintValue(int n) {return (longlong)UnalignedRead(n);}
+  virtual ulonglong GetUBigintValue(int n) {return (ulonglong)UnalignedRead(n);}
+  virtual double GetFloatValue(int n) {return (double)UnalignedRead(n);}
   virtual char  *GetCharString(char *p, int n);
-  virtual void   Reset(int n) {Typp[n] = 0;}
+  virtual void   Reset(int n) {UnalignedWrite(n, 0);}
 
   // Methods
   using VALBLK::SetValue;
   virtual void   SetValue(PSZ sp, int n);
   virtual void   SetValue(char *sp, uint len, int n);
   virtual void   SetValue(short sval, int n)
-  {Typp[n] = (TYPE)sval; SetNull(n, false);}
+  {UnalignedWrite(n, (TYPE)sval); SetNull(n, false);}
   virtual void   SetValue(ushort sval, int n)
-  {Typp[n] = (TYPE)sval; SetNull(n, false);}
+  {UnalignedWrite(n, (TYPE)sval); SetNull(n, false);}
   virtual void   SetValue(int lval, int n)
-  {Typp[n] = (TYPE)lval; SetNull(n, false);}
+  {UnalignedWrite(n, (TYPE)lval); SetNull(n, false);}
   virtual void   SetValue(uint lval, int n)
-  {Typp[n] = (TYPE)lval; SetNull(n, false);}
+  {UnalignedWrite(n, (TYPE)lval); SetNull(n, false);}
   virtual void   SetValue(longlong lval, int n)
-  {Typp[n] = (TYPE)lval; SetNull(n, false);}
+  {UnalignedWrite(n, (TYPE)lval); SetNull(n, false);}
   virtual void   SetValue(ulonglong lval, int n)
-  {Typp[n] = (TYPE)lval; SetNull(n, false);}
+  {UnalignedWrite(n, (TYPE)lval); SetNull(n, false);}
   virtual void