Horton

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

Bruce Momjian <bruce@momjian.us>

View thread
From: Bruce Momjian <bruce@momjian.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jeremy Drake <pgsql@jdrake.com>, Alvaro Herrera <alvherre@commandprompt.com>, pgsql-committers <pgsql-committers@postgresql.org>
Date: 2011-09-03T14:39:15Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Remove unnecessary #include references, per pgrminclude script.

  2. Remove "fmgr.h" include in cube contrib --- caused crash on a Gentoo

  3. Allow more include files to be compiled in their own by adding missing

  4. Add support for #elif to pgrminclude.

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