Christoph Berg <myon@debian.org> writes:
> 10beta3 and 9.6.4 are both failing during initdb on mips64el on
> Debian/sid (unstable):
> All other architectures have succeeded, as well as the 9.6.4 build for
> Debian/stretch (stable) on mips64el. The difference might be the
> compiler version (6.3.0 vs 7.1.0).
It's hard to explain that stack trace other than as a compiler bug.
There shouldn't be any event triggers active here, so
EventTriggerBeginCompleteQuery should have done nothing and returned
false. I don't put complete faith in gdb reports of local variable
values, but it says needCleanup = 0 '\000'
which agrees with that. Also the core dump appears to be because
currentEventTriggerState is NULL (please check that), which is
expected if EventTriggerBeginCompleteQuery did nothing. However, then
EventTriggerEndCompleteQuery should not have gotten called at all.
I suspect you could work around this with
bool isCompleteQuery = (context <= PROCESS_UTILITY_QUERY);
- bool needCleanup;
+ volatile bool needCleanup;bool commandCollected = false;
If that fixes it, it's definitely a compiler bug. That function does
not change needCleanup after the sigsetjmp call, so per POSIX it
should not have to label the variable volatile. This is far from
being the first such bug we've seen though.
regards, tom lane