[Postgres-xl-developers] running GTM under valgrind

Tomas Vondra tomas.vondra at 2ndquadrant.com
Thu Aug 24 07:52:05 PDT 2017


Hi,

On 08/24/2017 09:33 AM, Pavan Deolasee wrote:
> 
> 
> On Thu, Aug 24, 2017 at 5:16 AM, Tomas Vondra
> <tomas.vondra at 2ndquadrant.com <mailto:tomas.vondra at 2ndquadrant.com>> wrote:
> ...
> 
>     A typical example looks like this:
> 
>     ==11003== Invalid read of size 8
>     ==11003==    at 0x407878: GTM_ThreadCleanup (gtm_thread.c:373)
>     ==11003==    by 0x4079D5: GTM_ThreadMainWrapper (gtm_thread.c:431)
>     ==11003==    by 0x4E41739: start_thread (in
>     /usr/lib64/libpthread-2.24.so <http://libpthread-2.24.so>)
>     ==11003==  Address 0xec01e90 is 0 bytes inside a block of size 32
>     client-defined
>     ==11003==    at 0x431EEC: palloc0 (mcxt.c:804)
>     ==11003==    by 0x405087: GTMAddConnection (main.c:1460)
>     ==11003==    by 0x40462F: ServerLoop (main.c:1008)
>     ==11003==    by 0x404251: main (main.c:836)
> 
>     I'm no valgrind expert, but my understanding was this means we're
>     accessing data that may be uninitialized (like padding bytes in a
>     network message, etc.). But I'm not sure that's actually what's
>     happening here, as the value is allocated using palloc0().
> 
>     Anyone has an idea what is this about?
> 
> 
> Hmm. I am no expert either. But I spent quite sometime looking at those
> reports and reading code/valgrind docs and I still can't see why those
> accesses should be invalid. The doc
> (http://valgrind.org/docs/manual/mc-manual.html
> <http://valgrind.org/docs/manual/mc-manual.html>) says:
> 
> "Memcheck tries to establish what the illegal address might relate to,
> since that's often useful. So, if it points into a block of memory which
> has already been freed, you'll be informed of this, and also where the
> block was freed. Likewise, if it should turn out to be just off the end
> of a heap block, a common result of off-by-one-errors in array
> subscripting, you'll be informed of this fact, and also where the block
> was allocated. If you use the --read-var-info option Memcheck will run
> more slowly but may give a more detailed description of any illegal
> address."
> 
> May be we should try to run with --read-var-info option and see if we
> get more details?
> 

But this is from a run with -read-var-info=yes.


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


More information about the Postgres-xl-developers mailing list