RE: Huge memory consumed with myOdbc and VB.NET

> Attached is a working example and with a schema for the table.

Much better, thank you :-).

I can confirm your findings using MyODBC 3.51.12-2.

It seems to leak ~35 bytes per query with MissingSchemaAction
set to Add and ~563 bytes using AddWithKey, none of which seems
to be a leak in managed territory.

A wild speculation could be that .NET tickles a particular MyODBC
function that leaks a 512 byte buffer...

> The program exits after 500 queries on dataadapter.fill with
> exception, "Object reference not set to an instance of an object"
> and about 1.5 GB memory is consumed!

It's not quite as bleak here, I cannot reproduce that.

Which version of MyODBC are you using?
(Note that the only useful MyODBC release number is the one that was
 on the web page where you downloaded it - the version number on the
 DLL is most often grossly inaccurate.)

> The application runs on more then 10 other servers without problem,
> it's just related to one server.

By "server", do you mean "MySQL client running on a server"
or "MySQL server"?

Enough questions, carrying on...

A MyODBC trace from each scenario would be good, that way we could
compare and see if any extra or different calls are made when
MissingSchemaAction is set to AddWithKey.  Tracing seems to be
broken though, so we can't do that.

We can test if the number of rows has an effect on the amount
leaked.  Should be straightforward.

The schema does seem to have an effect, so another thing to try
could be to remove fields from the table per a binary search algorithm,
until we know what exactly triggers this bug.  With a little luck,
a particular nastyness in the schema (if any) can be found in less
than 10 tries.

Afterwards it could be helpful to try and run the test using another
database, just to be sure that it's really a MyODBC and not an ODBC
issue.  Although it is much more likely to be a MyODBC issue.

When we cannot get any further, filing a bug report on
http://bugs.mysql.com is probably the next logical step.

(I have an open bug that's soon 2 years old, so if there's any
 justice in the world, your issue will be fixed around 2008 ;-))

I've attached a modified version of your test case.
It's more complicated, but it can run without the user doing much
preparation.  Also it can keep track of it's own memory usage.

It comes with a neat and simple...

Reproduction recipe (-:
 - Setup MySQL server and database "test"
 - Install MyODBC, MDAC and .NET Framework v2
 - Fill in host, user, password and database in Module2.vbs
 - Compile: "c:\> vbc Module2.vbs"
 - Run Module2.exe

Reproduction recipe, not tickling leak:
 - set 'leak' to False in Module2.vbs
 - Compile
 - Rerun test

Would you mind running a test with the modified version?
Just to get some actual numbers to compare with.

If it crashes early on, you'll need to decrease runs to 500
and probeMargin to 100 or so to get any useful numbers out..



-- 
MySQL ODBC Mailing List
For list archives: http://lists.mysql.com/myodbc
To unsubscribe:    http://lists.mysql.com/myodbc?unsub=gcdmo-myodbc@xxxxxxxxxxx