PostgreSQL 8.4 crash on user defined C language function

SORRY FOR DUPLICATE EMAIL, I guess I'm really in pretty bad shape...

Hello,

I am experimenting with user defined functions in C, though I have
problem with stability.

It always crash on palloc() call, SPI_tuptable->tupdesc dereference
but not on SPI_* calls, for example.

Here is one modified example:

PGDLLIMPORT Datum test(PG_FUNCTION_ARGS)
{
       char *command;
       int ret;
       int proc;

       command = "SELECT 1";

       elog(INFO,"1");

       SPI_connect();

       elog(INFO,"2");

       ret = SPI_exec(command, 1);

       elog(INFO,"3");

       proc = SPI_processed;

       elog(INFO,"4");
       /*
        * If some rows were fetched, print them via elog(INFO).
        */
       if (ret > 0 && SPI_tuptable != NULL)
       {
           TupleDesc tupdesc = SPI_tuptable->tupdesc;
           SPITupleTable *tuptable = SPI_tuptable;
           char buf[8192];
           int i, j;

           elog(INFO,"5");
           for (j = 0; j < proc; j++)
           {
               HeapTuple tuple = tuptable->vals[j];

               elog(INFO,"6");
               for (i = 1, buf[0] = 0; i <= tupdesc->natts; i++)
               {
                       snprintf(buf + strlen (buf), sizeof(buf) -
strlen(buf), " %s%s",
                                SPI_getvalue(tuple, tupdesc, i),
                                (i == tupdesc->natts) ? " " : " |");

                       elog(INFO,"7");
               }
               elog(INFO, "EXECQ: %s", buf);
           }
       }

       SPI_finish();
       pfree(command);

}

"elog(INFO,"5");" line is not executed, I have to restart crashed
server after error:

LOG:  server process (PID 1628) was terminated by exception 0xC0000005
HINT:  See C include file "ntstatus.h" for a description of the
hexadecimal value.
LOG:  terminating any other active server processes

0xC0000005 is access violation, but I can't follow why.

I am using Visual Studio 2005 SP1 compiler. Since mine PostgreSQL 8.4
server uses msvcr71.dll, not 80, maybe it's compiler incompatibility
of some kind?