Tom Lane wrote: > Jeremy Drake <[email protected]> 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 <[email protected]> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
