Re: Leak repairs - Mailing list pgsql-odbc

I experimented almost the hole monday with dmalloc library.
So that was not efficient. I wanted to see, wether there
is a tool, that can debug the psqlodbc library behind
UnixODBC under Linux.

I don't have any Windows development environment.
I could though install Mingw into Windows XP.

So, the dmalloc library is under Debian Linux as a package
and easy to install though.

Here is, how I did it:
test.c:
#include <dmalloc.h>
test.c linking: gcc needed option -ldmallocth (threaded version).

I modified psqlodbclibpq in the following way:
PGAPI_AllocEnv() function in environ.c:
dmalloc_debug_setup("debug=0x4f4ed03,log=liblogfile");

This activates the memory debugging. liblogfile is the file, where the
results go.

PGAPI_FreeEnv() in environ.c:
dmalloc_shutdown(); // before return of return SQL_SUCCESS

Actually this setup crashes within dlclose inside UnixODBC library.
But, the debugging information will get written into "liblogfile",
because the log will be written inside PGAPI_FreeEnv().

I did compile test.c and psqlodbclibpq with -g and without optimizations
to achieve a good debugging environment.

This was the code block within an active connect:

  for (i=0; i<5; i++)
    {
      if
(!CHECK(SQL_HANDLE_DBC,m_conn,SQLAllocHandle(SQL_HANDLE_STMT,m_conn,&m_stmt)))
        return 1;

      if (!CHECK(SQL_HANDLE_STMT,m_stmt,SQLExecDirect(m_stmt,(SQLCHAR*)
"SELECT * FROM TEST1 LIMIT 100", SQL_NTS)))
        return 1;

      if (!CHECK(SQL_HANDLE_DBC,m_conn,SQLFreeStmt(m_stmt,SQL_DROP)))
        return 1;
    }



Marko Ristola

Dave Page wrote:

>
>
>
>
>>-----Original Message-----
>>From: pgsql-odbc-owner@postgresql.org
>>[mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Marko Ristola
>>Sent: 19 July 2005 08:37
>>Cc: Anoop Kumar; pgsql-odbc@postgresql.org
>>Subject: Re: [ODBC] Leak repairs
>>
>>
>>Have you seen this one?
>>
>>1121712844: 17186:  not freed: '0x404ef808|s1' (800 bytes) from
>>'qresult.c:421'
>>1121712844: 17186:  not freed: '0x404f0c08|s1' (800 bytes) from
>>'qresult.c:421'
>>1121712844: 17186:  not freed: '0x404fd008|s1' (3200 bytes) from
>>'qresult.c:421'
>>1121712844: 17186:  not freed: '0x404fe008|s1' (3200 bytes) from
>>'qresult.c:421'
>>1121712844: 17186:  not freed: '0x404ff008|s1' (3200 bytes) from
>>'qresult.c:421'
>>1121712844: 17186:  not freed: '0x40500008|s1' (3200 bytes) from
>>'qresult.c:421'
>>1121712844: 17186:  not freed: '0x40501008|s1' (3200 bytes) from
>>'qresult.c:421'
>>
>>Line 421 allocates a buffer into QResultClass.backend_tuples.
>>
>>backend_tuples will be set into NULL in QR_Destructor() with
>>"self->backend_tuples = NULL". I suspect, that the memory leak.
>>
>>
>>
>
>Nicely spotted :-)
>
>That would appear to be the last of them (at least for my simple testing
>at the moment). I'll commit a patch shortly.
>
>BTW, I assume you got that output from the VC++ debugger - care to share
>how? I spent quite some time trying to persuade it to give me that and
>didn't get anywhere :-(
>
>Regards, Dave.
>
>---------------------------(end of broadcast)---------------------------
>TIP 9: In versions below 8.0, the planner will ignore your desire to
>       choose an index scan if your joining column's datatypes do not
>       match
>
>