MySQL Bugs: #6409: possible memory leak

Bug #6409	possible memory leak
Submitted:	3 Nov 2004 18:10	Modified:	30 May 2013 12:34
Reporter:	[ name withheld ]	Email Updates:
Status:	Closed	Impact on me:	None
Category:	Connector / ODBC	Severity:	S3 (Non-critical)
Version:	3.51.06	OS:	Windows (Windows 2000 server)
Assigned to:	Assigned Account	CPU Architecture:	Any

Description:
Have noticed that after (usually) a few weeks myodbc driver will stop functioning, returning error "out of memory".  not only does our mssqlserver receive this error from myodbc via the linked server, but running a test via the Test button on the odbc gui will yield this error too.
 
since there is no way (I know of) to restart the driver/dll itself, we are forced to restart to application using it (ms sqlserver).
 

How to repeat:
create linked server from ms sqlserver. query and update repeadedly via view such as:
CREATE VIEW sipsubs AS SELECT * FROM OPENQUERY(sipdb, 'select * from ser.subscriber') 

probelm usuually surfaces about once a month.

i was able to verify this but by executing the following:

for i =1; i<=100000000; i++
CREATE VIEW sipsubs%i AS SELECT * FROM OPENQUERY(sipdb, 'select * from
my.user')

We are unable to reproduce the behaviour.

This is what we tried:

> > CREATE VIEW ... query uses the same ODBC API functions that INSERT
> > INTO MSSQLTestDB.myTestTable SELECT * FROM OPENQUERY(sipdb, 'select *
> > from
> > ser.subscriber')
> > (SQLAllocHandle/FreeHandle, SQLSetEnvAttr, SQLGetInfo,
> > SQLGet/SetConnectAttr, SQLDriverConnect, SQLGetDiagRec, SQLGetInfo,
> > SQLPrepare, SQLExecDirect etc)
> > So we made my tests with INSERT instead of CREATE VIEW because
> > Microsoft SQL works very much slowly after 100 000 CREATE VIEW
> > operations.
> > INSERT query was performed about 30 000 000 times. During this time
> > sqlsrvr.exe process had taken all free memory (200Mb RAM and 273Mb
> > Virtual memory from 256 Mb RAM and 512 Mb swap file). At least it
> > stopped while system had displayed "Out of system memory" alert and
> > only free 4Mb remained.
> > Every attempt to open any program caused "Not enough resources" alert.
> > sqlsrvr.exe functioned after I run INSERT queries anew, but didn't
> > dispose the memory taken before. I thought I recreated the error.
> > After Microsoft SQL restart all resources were disposed and system had
> > a lot of free memory.
> >
> > After that we had made another test, without ODBC Connector. Microsoft
> > SQL copied some data from one table to another. And the same situation
> > with system memory was repeated.

The above means that leak is NOT in Connector/ODBC.

> > On other side: my program that read the data from ODBC driver from the
> > same DSN worked 30 000 000 times without problems and visible memory
> > leaks.
> >
> > I think it is a peculiarity of Microsoft SQL or something like that.

Can you send us additional info on how we can reproduce this ??

Please do note that we used 3.51.11-2.

We also tried the following:

> > we had performed some tests to recreate the error (out of memory in
> > ODBC/Connector dll):
> > - ODBC Connector 3.51.11
> > - MySQL 4.1.11 and 4.1.1 alpha (each version was tested with the
> > connector) - Microsoft SQL Server 2000 SP3
> > -----------------
> > Created linked server and run following queries:
> >
> > for i =1; i<=500000; i++
> > CREATE VIEW sipsubs%i AS SELECT * FROM OPENQUERY(sipdb, 'select * from
> > my.user')
> >
> > and
> >
> > for i =1; i<=10000000; i++
> > INSERT INTO MySQLTest SELECT * FROM OPENQUERY(sipdb, 'select * from
> > my.user')
> >
> > out of memory error was not displayed.
> > also we wrote a program on C++ and run SELECT * FROM my.user
> > 10 000 000 times
> >

Any comments ??

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

I'm closing this bug because I can not continue without feedback from the reporter. If you have new info, please reopen the report.