My code, which works fine in Linux (Ubuntu 10.10) looks like this:

Connection conn(false);
conn.connect(db, server, user, pass)
Transaction trans(conn);
Query query = conn.query("Update blah blah");
query.execute(); // inside try,catch,catch block
query << "Another update";
query.execute(); //try
query << "Yet another";
query.execute; //try
query << "select this, that and the other thing";
vector<deepskyStruct> resvec; // deepskyStruct is an ssqls structure
vector<deepskyStruct>::iterator it;
for loop through the vector, creating members of class SessionObject from the data
end for

start another transaction
query << "Update a different table";
query.execute(); //two more of these
query << "Select blah, blah blah from a different table";
vector(doubleStarStruct> resvec2;

//Up to here, everything is fine, and I have verified that all the updates took place. I also know that the first select, storing in resvec, creating the objects, etc. worked, because when I commented out the stuff for the 2nd table the program completed successfully with the expected output.



402 query.storein(resvec2);
(gdb) next

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0000041c
0x93d12a8d in std::string::clear ()

I debugged the process in XCode:

Here is the calling sequence:

query.storein(resvec); // this is in mycode

storein(Container & con); // in the Mysql++ library
storein(con, str(template_defaults) );
storein_sequence(con, s); // s is a const SQLTypeAdapter
UseQueryResult result = use(s);
while(1) {MYSQL_ROW d = result.fetch_raw_row();

the UseQueryResult object result has a private member result_ with these members:

The first time I call query.storein(resvec), after use(s), the result object has these values:
counted_ = 0x5016f0
refs = 0x501cd0

The code works fine.
When, after another query to a different table, I call query.storein(resvec2), after the use(s), the members counted_ and refs_ are both 0x0. Then, when result.fetch_raw_row is called, the program gets the EXC_BAD_ACCESS error. The debugger window shows this:

0x98d17a7c <+0000> push ebp
0x98d17a7d <+0001> mov ebp,esp
0x98d17a7f <+0003> sub esp,0x18
0x98d17a82 <+0006> mov eax,DWORD PTR [ebp+0x8]
0x98d17a85 <+0009> mov DWORD PTR [esp+0xc],0x0
0x98d17a8d <+0017> mov edx,DWORD PTR [eax]

the last line is highlighted and a red arrow points to it.

Alan Shank
Woodland, CA

Search Discussions

  • Warren Young at Feb 19, 2011 at 12:13 am

    On Feb 17, 2011, at 11:55 AM, Alan Shank wrote:

    My code, which works fine in Linux (Ubuntu 10.10)
    I suspect that if you run it under Valgrind on Linux it will catch a bug there, too. Working isn't the same as being correct. :)
    vector<deepskyStruct>::iterator it;
    for loop through the vector, creating members of class SessionObject from the data
    end for
    Move the vector inside the loop, so it gets completely destroyed then rebuilt on each query. As your code is structured now, each query after the first is going to *append* its results to this result set.

    Alternately, you can say "resvec.clear()" on each iteration, which may be slightly more efficient. (Or might not. Benchmark to find out, if it matters.)

    It's possible that your bug is simply due to running the PC out of memory.
  • Warren Young at Feb 19, 2011 at 6:16 pm
    Alan, please keep replies on the list.
    On 2/19/2011 10:21 AM, Alan Shank wrote:

    Move the vector inside the loop,
    I don't think you have understood this code.
    Quite possible, since you haven't actually provided *code*, just
    pseudocode. If you want people to do more than just skim, you're going
    to have to provide something that compiles and is based on one of the
    examples so they don't need your database. If you aren't willing (or
    able) to provide something that demonstrates the problem in a way people
    can see on their own machines, you have to expect incomplete clarity in
    replies, because the problem is unclear in your respondent's heads.

    Nevertheless, nothing in what you say tells me that the vector gets
    cleared or rebuilt between queries, which means it's going to continue
    to be appended to. Study Query::storein_sequence(), beginning at line
    749 or so in lib/query.h. Notice that it does not clear or resize the
    container. That's your job. It *does not* work like Query::store() in
    this regard.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupplusplus @
postedFeb 17, '11 at 6:55p
activeFeb 19, '11 at 6:16p

2 users in discussion

Warren Young: 2 posts Alan Shank: 1 post



site design / logo © 2022 Grokbase