Re: Question on stability of results returned by C api mysql_fetch_row()

I think I found my problem, and I'm kicking myself for it

On Thu, 11 Feb 2021 16:27:19 +0000, Lew Pitcher wrote:

> I have written a C program that summarizes the contents of a table. It
> only "SELECT"s from the table, and retrieves rows using mysql_fetch_row
> (). As the program must interpret the row data, it may need to work with
> as many as five (5) rows as a time.
> 
> I'm chasing down a memory corruption problem with this program, that
> seems to overwrite the stored row data, and I want to eliminate my use
> (or possibly, misuse) of the C api as the source.

OK, here's the thing. While performing some subsequent processing on the 
returned resultset (call this the "primary" results), I conditionally 
execute a second query against a history table, using values from the 
"primary" results row. I then INSERT selected values from "primary" 
results, along with the results of that secondary query, into a temporary 
table. Once I've processed all the "primary" results, I then run a query 
against this temporary table, and generate a report from /those/ results.

Somewhere in this process, I sometimes run into a "segmentation 
violation" (a Unix SIGSEGV), which generally indicates that I've tried to 
access memory that I have no access to (outside of my address space, not 
mapped, etc.). Initial debugging showed that the values in the "primary" 
resultset had changed, in ways that would cause a SIGSEGV, hence my 
original question regarding the stability of the resultset.

Further debugging traced my problem to the history table query. When I 
designed the table, I knew that it was possible that a query would 
retrieve NO rows from the table. I /thought/ that my program logic 
handled that condition. I was wrong. :-(

So, I've remedied that oversight, and only process that secondary query's 
returned row if the mysql_num_rows() is greater than zero. When I /did 
not/ do this, sometimes the query would return an empty resultset, and 
I'd grab a data-item pointer that wasn't initialized, and off I'd go into 
SIGSEGV territory. Now, with the mysql_num_rows() test guarding the data, 
I only grab a data-item pointer when I actually have one.

Thanks to all who made suggestions. You helped me see my code in a new 
light and discover my oversight.
-- 
Lew Pitcher
"In Skills, We Trust"