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

On Fri, 2 Sep 2011, Tom Lane wrote:

> Yeah, so the next question would be why those other ones aren't showing
> problems.  But at least now we have a potential mechanism for getting
> from "the include list changed" to "cube is crashing on an offsetof",
> namely that something is affecting the expansion of the offsetof macro.
> Up to now it's been black magic, and I don't like patching around
> problems we don't understand any better than that.


I'm going to try answering about 3 emails at once here, so I apologize for
the confusion.

Checking preprocessor output on cube_f8_f8 between working and broken, the
output was identical for that function.

Changing offsetof(NDBOX, x[0]) to offsetof(NDBOX, x), no change in
behavior.

Then I started investigating the disassembly.  The PIC disassembly was
making my head hurt (why is the compiler calling the next instruction,
popping the return address into a register, and using it as a pointer?
Oh yeah, PIC, duh!), but I'm pretty sure that what it crashed on was
attempting to access the global external variable CurrentMemoryContext.
The odd thing is, that the disassembly code between the working and
non-working was the same, except for the offsets.

Here's the disassembly output from the core dump:
Program terminated with signal 11, Segmentation fault.
#0  cube_f8_f8 () at cube.c:1435
1435        size = offsetof(NDBOX, x) +sizeof(double) * 2;
(gdb) set disassembly-flavor intel
(gdb) disass
Dump of assembler code for function cube_f8_f8:
   0xb776ab50 <+0>:    push   ebp
   0xb776ab51 <+1>:    mov    ebp,esp
   0xb776ab53 <+3>:    and    esp,0xfffffff8
   0xb776ab56 <+6>:    push   ebx
   0xb776ab57 <+7>:    sub    esp,0x14
   0xb776ab5a <+10>:    mov    ecx,DWORD PTR [ebp+0x8]
   0xb776ab5d <+13>:    mov    DWORD PTR [esp+0x10],ebx
   0xb776ab61 <+17>:    mov    edx,DWORD PTR [ecx+0x14]
   0xb776ab64 <+20>:    movsd  xmm0,QWORD PTR [edx]
   0xb776ab68 <+24>:    mov    edx,DWORD PTR [ecx+0x18]
   0xb776ab6b <+27>:    movsd  xmm1,QWORD PTR [edx]
   0xb776ab6f <+31>:    movsd  QWORD PTR [esp],xmm0
   0xb776ab74 <+36>:    movsd  QWORD PTR [esp+0x8],xmm1
   0xb776ab7a <+42>:    push   0x18
   0xb776ab7c <+44>:    call   0xb776ab81 <cube_f8_f8+49>
   0xb776ab81 <+49>:    pop    eax
   0xb776ab82 <+50>:    add    eax,0x9472
   0xb776ab87 <+55>:    mov    edx,DWORD PTR [eax-0x58]
=> 0xb776ab8d <+61>:    push   DWORD PTR [edx]
   0xb776ab8f <+63>:    mov    DWORD PTR [esp+0x18],ebx
   0xb776ab93 <+67>:    mov    ebx,eax
   0xb776ab95 <+69>:    call   0xb776745c <MemoryContextAllocZero@plt>



With this knowledge, I thought maybe cube wasn't the actual problem, but
just happened to be early in the list of contrib modules being tested.  So
I arbitrarily picked another contrib module to test, intarray.

============== running regression test queries        ==============
test _int                     ... FAILED (test process exited with exit
code 2)

Program terminated with signal 11, Segmentation fault.
#0  0xb785a1fa in g_intbig_union ()
   from
/buildfarm/test/pgsql_test/contrib/intarray/tmp_check/install/usr/local/pgsql/lib/_int.so
(gdb) set disassembly-flavor intel
(gdb) disass
Dump of assembler code for function g_intbig_union:
<SNIP UNRELATED ASSEMBLY CODE>
   0xb785a087 <+31>:    call   0xb785a08c <g_intbig_union+36>
   0xb785a08c <+36>:    pop    eax
   0xb785a08d <+37>:    add    eax,0x6f67
   0xb785a092 <+42>:    mov    DWORD PTR [esp+0x104],eax
<SNIP MORE UNRELATED ASSEMBLY CODE (this is a much longer function)>
   0xb785a1e5 <+381>:    mov    eax,DWORD PTR [esp+0x104]
   0xb785a1ec <+388>:    mov    esi,DWORD PTR [eax-0x24]
   0xb785a1f2 <+394>:    mov    DWORD PTR [esp+0x108],ebx
   0xb785a1f9 <+401>:    push   ebx
=> 0xb785a1fa <+402>:    push   DWORD PTR [esi]
   0xb785a1fc <+404>:    mov    DWORD PTR [esp+0x104],ebx
   0xb785a203 <+411>:    mov    ebx,eax
   0xb785a205 <+413>:    call   0xb7853ef0 <MemoryContextAlloc@plt>


Looks pretty familiar, right?

Still, I have no idea why adding an include would cause issues accessing
CurrentMemoryContext.  But at least we're not blaming offsetof or cube
anymore...