Re: Postgres 9.0 crash on win7

On 4/10/2010 10:56 AM, Tom Lane wrote:
> Craig Ringer<craig(at)postnewspapers(dot)com(dot)au> writes:
>> While it's consistently crashing my Pg 9 on win7 32-bit, too, I haven't
>> been able to get a backtrace yet. I thought it'd be trivial given the
>> ease of reproducing the crash - but the process that's crashing isn't
>> the backend running the query.
>
>> It looks like it's one of the helpers like the stats collector, autovac,
>> bgwriter, etc. I'm unsure which yet.
>
> I'd bet on autovacuum. You might be able to reproduce the crash in the
> foreground process by issuing a manual VACUUM or ANALYZE.

Thanks. I wasn't able to get the backend running the script to crash
initially, even with an explicit VACUUM, ANALYZE, or VACUUM ANALYZE.
After turning autovacuum off completely, though, it does crash when
ANALYZE is run.

> postgres.exe!pfree(void * pointer=0x68f08610) Line 591 + 0x3 bytes C
> postgres.exe!examine_attribute(RelationData * onerel=0x00000000, int attnum=5, Node * index_expr=0x00000000) Line 877 C
> postgres.exe!do_analyze_rel(RelationData * onerel=0x01747b48, VacuumStmt * vacstmt=0x01690580, char update_reltuples='
', char inh=0) Line 357 + 0xa bytes C
> postgres.exe!analyze_rel(unsigned int relid=131097, VacuumStmt * vacstmt=0x01690580, BufferAccessStrategyData * bstrategy=0x018fc0f0, char update_reltuples='
') Line 232 C
> postgres.exe!vacuum(VacuumStmt * vacstmt=0x01690580, unsigned int relid=0, char do_toast='
', BufferAccessStrategyData * bstrategy=0x018fc0f0, char for_wraparound=0, char isTopLevel='
') Line 248 C
> postgres.exe!standard_ProcessUtility(Node * parsetree=0x01690580, const char * queryString=0x0168fc78, ParamListInfoData * params=0x00000000, char isTopLevel='
', _DestReceiver * dest=0x01690730, char * completionTag=0x004ff998) Line 1012 + 0x13 bytes C
> postgres.exe!PortalRunUtility(PortalData * portal=0x00000000, Node * utilityStmt=0x00000000, char isTopLevel='
', _DestReceiver * dest=0x01690730, char * completionTag=0x004ff998) Line 1199 C
> postgres.exe!PortalRunMulti(PortalData * portal=0x00000000, char isTopLevel='
', _DestReceiver * dest=0x01690730, _DestReceiver * altdest=0x01690730, char * completionTag=0x004ff998) Line 1298 + 0x11 bytes C
> postgres.exe!PortalRun(PortalData * portal=0x016dd028, long count=2147483647, char isTopLevel='
', _DestReceiver * dest=0x01690730, _DestReceiver * altdest=0x01690730, char * completionTag=0x004ff998) Line 823 + 0x17 bytes C
> postgres.exe!exec_simple_query(const char * query_string=0x00000000) Line 1059 C
> postgres.exe!PostgresMain(int argc=2, char * * argv=0x01635220, const char * username=0x009780b0) Line 3871 C
> postgres.exe!BackendRun(Port * port=0x00000002) Line 3550 + 0x17 bytes C
> postgres.exe!SubPostmasterMain(int argc=3, char * * argv=0x00972878) Line 4042 + 0x8 bytes C
> postgres.exe!main(int argc=3, char * * argv=0x00972878) Line 165 + 0x7 bytes C
> postgres.exe!__tmainCRTStartup() Line 586 + 0x17 bytes C
> kernel32(dot)dll!(at)BaseThreadInitThunk@12() + 0x12 bytes
> ntdll(dot)dll!___RtlUserThreadStart(at)8() + 0x27 bytes
> ntdll(dot)dll!__RtlUserThreadStart(at)8() + 0x1b bytes

It's crashing in pfree, as called by examine_attribute here:

if (!ok || stats->compute_stats == NULL || stats->minrows <= 0)
{
pfree(stats->attrtype);
pfree(stats->attr); <-- crash
pfree(stats);
return NULL;
}

... which is palloc'd earlier in examine_attribute.

VC++ is having trouble examining the locals in examine_attribute(); I'm
unsure if this is an optimization issue, lack of full debug info, or
something wrong with the state of the stack.

It's definitely crashing while analyzing the relation "suolo" - not only
do the logs show analysis beginning, but onerel->rd_rel->relname is
"suolo". At the time of the crash it seems to have already added the
column with attr->attname = "codpoligono" to vacattrstats and is
examining the column with attnum=5 when it crashes. A quick look at
pg_class and pg_attribute shows that this is (surprise!) the "geom"
column of type "geometry".

PostGIS on Windows is a bit outside my depth, especially as it's not a
neat crash in the analyze function its self. Hopefully this'll give the
PostGIS folks something to go on, though. Andrea: please pass it on.

--
Craig Ringer

Tech-related writing at http://soapyfrogs.blogspot.com/