MySQL Bugs: #42161: mysql_fetch_row returns NULL, mysql_errno returns 0, but rows SHOULD BE fetched

Bug #42161	mysql_fetch_row returns NULL, mysql_errno returns 0, but rows SHOULD BE fetched
Submitted:	16 Jan 2009 15:47	Modified:	25 Feb 2009 20:57
Reporter:	Jon Vance	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server: C API (client library)	Severity:	S3 (Non-critical)
Version:	5.1	OS:	Windows (XP Pro)
Assigned to:		CPU Architecture:	Any
Tags:	mysql_fetch_row NULL mysql_errno

Description:
My program initiates a query using mysql_query, then accesses the return using mysql_use_result and finally mysql_fetch_row.  Under very rare and specific circumstances, the latter function returns NULL even when there absolutely are matching rows in the table.  mysql_errno returns zero, and when analyzing the structure returned from mysql_use_result, the rowcount field is zero.

Note that I have tried swapping out mysql_use_result with mysql_store_result and the same thing occurs.

How to repeat:
Unfortunately it is such a rare occurrence, that though it is repeatable in my program, I have not been able to produce a simple recreation.  It seems as though the entire application has to be there.

Thank you for the bug report. We don't have similar case reported and processed so it is very hard to say you there is a bug here without a C code test case. Reopen this bug report if you will be able to get a repeatable test case together with table's dump file and my.ini file. Thanks in advance.

Jon,

  Did you ever figure out what the cause of your problem was?  I'm encountering this problem as well, and I'm [so far] unable to find a cause.

-Brian

Unfortunately, no.  Make sure you check mysql_errno to see if there is an error.  If no error, and you're completely sure the query should generate results, then you have found the same bug.  Maybe you can create a more useful reproduction case!

I've tried older versions of libmysql.dll as well as the latest, and nothing seems to help.

For future reference in case anyone else encounters this problem, I setup query logging in mysql to verify the query received is correct and there's a discrepancy.  Results from printf to stdout of the query string passed to executeFormattedQuery:

select (...) WHERE id = 104

The query that shows up in the mysql general log:

select (...) WHERE id = 1916231776

  I have not as-yet found a cause.  The code I'm working on was originally targeting a 32-bit platform and was working fine with mysql 5.0 libraries.  On my 64-bit machine I have mysql 5.1 installed.

-Brian

... and it appears the number that shows up in the "id = X" part is random.  Multiple runs of the same program with the same parameters produce different numbers.

-Brian

Scratch what I said there, apparently this api was written by one of my co-workers and I blindly assumed he was using the mysql api.

-Brian

brian:  looks like you're misusing printf format specifiers.  Check they are correct type %d, %lu, etc.

jon: Are you sharing mysql connection between multiple threads?  If so, this is wrong and each thread should have it's own connection.

Nope.  Very careful to create a separate connection for each thread.

Nah.  I tracked down where my problem is coming from, has nothing to do with the mysql api, it would seem.  Someone had created an executeFormattedQuery function, which used a function from another class.  In the executeFormattedQuery function it created a va_list variable, called va_start, then passed the va_list arg to another function.  That function uses vsnprintf to try printing to a buffer.  If the buffer isn't big enough, the buffer size is increased and vsnprintf is called again with the same va_list as an argument, but va_end() is not called (followed by another va_start()), which, for some reason on a 32-bit platform works fine (at least under some circumstances), but in a 64-bit environment causes problems.

Jon,

thank you for the feedback. Please turn on logging for your mysqld server application, so you can catch which queries and under which circumstances cause the problem. (You can also try MySQL Proxy with customs script as alternative to the general log file.)

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".