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

On 13/02/2021 23:13, Lew Pitcher wrote:
> 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.
> 
Ok. I've done similar. It works. With caveats

> 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.
> 
As I said C wont wipe your botty, But it will do exactly what you tell 
it to!



-- 
“when things get difficult you just have to lie”

― Jean Claud Jüncker