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

Did you test with a lower optimization level?  Gentoo is notorious for
buggy/bleeding edge tools.

---------------------------------------------------------------------------

Jeremy Drake wrote:
> 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...
>

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

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