List:MySQL++« Previous MessageNext Message »
From:Warren Young Date:April 13 2011 5:53am
Subject:Re: Crash in DBDriver::fetch_row on a heavily loaded system...
View as plain text  
On 4/12/2011 9:02 PM, Adrian Cornish wrote:
>> I also wonder whether, given the potential circumstances for this problem
>> to crop up, if Query::result_empty() should have additional checks on conn_
>> and conn->driver().
>>
>
> What about modifying either following 3 functions to check driver_ before
> use
>
> result.cpp:161 UseQueryResult::fetch_lengths() const  and
> result.cpp:165 Row UseQueryResult::fetch_row() const
> result.cpp.202 MYSQL_ROW UseQueryResult::fetch_raw_row() const

Seems like overkill.

My purpose in thinking about what else should be checked is only to see 
if I can identify, while I'm touching this bit of code, other things 
that could break.  I don't intend to check everything just to check it. 
  I may even elect not to check some things that could break, for "fail 
early" philosophical reasons.

The patch I just made isn't one of those areas where MySQL++ should fail 
early, because it's not the end user's fault MySQL++ is in a broken 
state.  Only MySQL++ code can detect this condition and react correctly 
to it.

> throwing from the constructor of ResultBase instead?

I don't see how ResultBase can know when to do that.

All ResultBase gets is a pointer to the MYSQL_RES structure the C API 
allocated, and this pointer is NULL when there is no result set, as in 
the case of INSERT, CREATE, etc.  ResultBase is at too low a level to 
have enough context to understand these distinctions.  Its only purpose 
is to carry a result set, not to make any interpretations about it.

To have that context, you need to know what query was given and which of 
the three major query execution call types you used.  Most of the time, 
that means it's up to user code, but in this case, it's one of the few 
places where MySQL++ calls use() itself, so *it* has the needed context 
instead.
Thread
Crash in DBDriver::fetch_row on a heavily loaded system...dancook)12 Apr
  • Re: Crash in DBDriver::fetch_row on a heavily loaded system...Adrian Cornish12 Apr
    • RE: Crash in DBDriver::fetch_row on a heavily loaded system...dancook)12 Apr
    • RE: Crash in DBDriver::fetch_row on a heavily loaded system...dancook)13 Apr
      • Re: Crash in DBDriver::fetch_row on a heavily loaded system...Warren Young13 Apr
        • Re: Crash in DBDriver::fetch_row on a heavily loaded system...Adrian Cornish13 Apr
          • Re: Crash in DBDriver::fetch_row on a heavily loaded system...Warren Young13 Apr
        • RE: Crash in DBDriver::fetch_row on a heavily loaded system...dancook)15 Apr
          • Re: Crash in DBDriver::fetch_row on a heavily loaded system...Warren Young15 Apr
            • Re: Crash in DBDriver::fetch_row on a heavily loaded system...Warren Young15 Apr
            • RE: Crash in DBDriver::fetch_row on a heavily loaded system...dancook)16 Apr
              • Re: Crash in DBDriver::fetch_row on a heavily loaded system...Warren Young16 Apr
          • SSQLS: Number of colomns in a tabledancook)19 May
            • Re: SSQLS: Number of colomns in a tableAdrian Cornish19 May
            • Re: SSQLS: Number of colomns in a tableAdrian Cornish19 May
              • Re: SSQLS: Number of colomns in a tableWarren Young19 May
                • Re: SSQLS: Number of colomns in a tableAdrian Cornish19 May
                  • RE: SSQLS: Number of colomns in a tabledancook)19 May
                  • Re: SSQLS: Number of colomns in a tableWarren Young19 May
                    • Re: SSQLS: Number of colomns in a tableWarren Young20 May
      • Re: Crash in DBDriver::fetch_row on a heavily loaded system...Adrian Cornish13 Apr
        • Re: Crash in DBDriver::fetch_row on a heavily loaded system...Warren Young13 Apr