Re: pgsql: Remove "fmgr.h" include in cube contrib --- caused crash on a Ge - Mailing list pgsql-committers

From Bruce Momjian
Subject Re: pgsql: Remove "fmgr.h" include in cube contrib --- caused crash on a Ge
Date
Msg-id 201109031439.p83EdFA18865@momjian.us
Whole thread Raw
In response to Re: pgsql: Remove "fmgr.h" include in cube contrib --- caused crash on a Ge  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-committers
Tom Lane wrote:
> Jeremy Drake <pgsql@jdrake.com> writes:
> > ... I'm pretty sure that what it crashed on was
> > attempting to access the global external variable CurrentMemoryContext.
>
> Ah-hah, good insight!
>
> > The odd thing is, that the disassembly code between the working and
> > non-working was the same, except for the offsets.
>
> The code seems to be fetching a pointer to CurrentMemoryContext from a
> PC-relative location; presumably that's a literal that the dynamic
> linker is supposed to update at shlib load time.  I guess that pointer
> is not correctly computed in the other case, or else it's fetching the
> wrong pointer value.

This would explain why the regular regression test work but the /contrib
modules, which do dynamic loading, do not.   Good to know the problem is
more the contrib/cube.  FYI, I noticed in the contrib/cube failure that
palloc0() was the next line after the reported crash line.   Are the
contrib's crashing on the first access of any backend/DLL function?

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

pgsql-committers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pgsql: Remove "fmgr.h" include in cube contrib --- caused crash on a Ge
Next
From: Tom Lane
Date:
Subject: pgsql: Rearrange planner to save the whole PlannerInfo (subroot) for a