Craig Ringer <craig@2ndquadrant.com> writes:
> I have absolutely no idea why it's trying to access memory at what looks
> like (uint64)(-1) though. Nothing in the auto vars list:
> + &restrictlist 0x000000000043f7b0 {0x0000000009e32600 {type=T_List (656)
> length=1 head=0x0000000009e325e0 {data={ptr_value=...} ...} ...}} List * *
> + inner_rel 0x0000000009e7ad68 {type=T_EquivalenceClass (537)
> reloptkind=RELOPT_BASEREL (0) relids=0x0000000009e30520 {...} ...} RelOptInfo
> *
> + inner_rel->relids 0x0000000009e30520 {nwords=658 words=0x0000000009e30524
> {...} } Bitmapset *
> + outer_rel 0x00000001401dec98
> {postgres.exe!build_joinrel_tlist(PlannerInfo * root, RelOptInfo * joinrel,
> RelOptInfo * input_rel), Line 646} {...} RelOptInfo *
> + outer_rel->relids 0xe808498b48d78b48 {nwords=??? words=0xe808498b48d78b4c
> {...} } Bitmapset *
> + sjinfo 0x000000000043f870 {type=T_SpecialJoinInfo (543)
> min_lefthand=0x0000000009e7abd0 {nwords=1 words=0x0000000009e7abd4 {...} }
> ...} SpecialJoinInfo *
inner_rel seems to be pointing at garbage, or at least why is the
referenced object tag T_EquivalenceClass not T_RelOptInfo? And
why aren't we being given anything for outer_rel? The value for
outer_rel->relids isn't inspiring any confidence either, and
for that matter inner_rel->relids couldn't possibly have more than
nwords==1 given how simple the query is. In short, either the
debugger is totally confused or the code is, because most of these
pointers aren't pointing at anything sane.
TBH, this looks more like a compiler bug than anything else. I wonder
whether it's getting confused by taking the address of a parameter
(although surely we do that elsewhere).
It would be worth recompiling at -O0, or whatever the local equivalent
of that is, to see if (1) the crash goes away or (2) the debugger's
printouts get any more reliable.
regards, tom lane