Re: MySqlEXDI Segfaults but a few ideas

The hole interface is build on the base of the mysql 4.1x client libraries (headers). I always use a 4.1.11 client library to access a 5.x database, and I have no segfaults. Maybe there are changes in the 5.x client libraries.


Thomas Gagné wrote:

I'm able to most selects to work, and was able to create a store database on a 5.0.24 server.  This is good news.

Through the ad-hoc query tool I was unable to get "show tables" to work in the store database.  I get a segfault. 

The size of a composite really shouldn't affect the behavior of the image if Smalltalk isn't responsible for allocating or deallocating its memory, should it?  Just to make sure, might it be a good idea just to make as many structure pointers as possible to be simple pointers (void *)?

I agree, it is probably a good idea to alter most of the structured pointers to opaque pointers to avoid compatibility problems.

Thomas Gagné wrote:

I'm fixing the size of some of the structures (I'm getting segfaults).  A few of those I've checked were short.  For some of them, instead of trying to get the members right I just created structs of { short shorts[sizeinbytes/2]; }.

In #acquireBuffers, I'm wondering if there was a reason you used #malloc instead of #gcMalloc?  It does look like you free the memory later in #freeOutputBuffersPointer so that isn't a problem.  I'm just wondering why?

-- 
Visit <http://tggagne.blogspot.com/>,<http://gagne.homedns.org/> or
      <http://gagne.homedns.org/~tgagne/> for more great reading.
  

-- 
Visit <http://tggagne.blogspot.com/>,<http://gagne.homedns.org/> or
      <http://gagne.homedns.org/~tgagne/> for more great reading.
  

Olaf Urban wrote:
 > The hole interface is build on the base of the mysql 4.1x client
 > libraries (headers). I always use a 4.1.11 client library to access a
 > 5.x database, and I have no segfaults. Maybe there are changes in the
 > 5.x client libraries.

Doesn't this imply that we need to implement different driver classes
for the various MySQL API versions?
Perhaps they can be switched automatically if MySQL provides a version()
function....

R
-


 >
 >
 > Thomas Gagné wrote:
 >> I'm able to most selects to work, and was able to create a store
 >> database on a 5.0.24 server.  This is good news.
 >>
 >> Through the ad-hoc query tool I was unable to get "show tables" to
 >> work in the store database.  I get a segfault.
 >>
 >> The size of a composite really shouldn't affect the behavior of the
 >> image if Smalltalk isn't responsible for allocating or deallocating
 >> its memory, should it?  Just to make sure, might it be a good idea
 >> just to make as many structure pointers as possible to be simple
 >> pointers (void *)?
 > I agree, it is probably a good idea to alter most of the structured
 > pointers to opaque pointers to avoid compatibility problems.
 >>
 >> Thomas Gagné wrote:
 >>> I'm fixing the size of some of the structures (I'm getting
 >>> segfaults).  A few of those I've checked were short.  For some of
 >>> them, instead of trying to get the members right I just created
 >>> structs of { short shorts[sizeinbytes/2]; }.
 >>>
 >>> In #acquireBuffers, I'm wondering if there was a reason you used
 >>> #malloc instead of #gcMalloc?  It does look like you free the memory
 >>> later in #freeOutputBuffersPointer so that isn't a problem.  I'm just
 >>> wondering why?
 >>> --
 >>> Visit <http://tggagne.blogspot.com/>,<http://gagne.homedns.org/> or
 >>>       <http://gagne.homedns.org/~tgagne/> for more great reading.
 >>>
 >>
 >> --
 >> Visit <http://tggagne.blogspot.com/>,<http://gagne.homedns.org/> or
 >>       <http://gagne.homedns.org/~tgagne/> for more great reading.
 >>

I was just debugging the libmysqlclient.so.  With 7.2.1, A MYSQL_RES *
is stored inside Smalltalk correctly, but when it gets to
mysql_store_result() its value becomes 0x19.

I tried with 7.4 and though I got past that one, but it blew up with a
segfault publishing a package elsewhere.

--
Visit <http://tggagne.blogspot.com/>,<http://gagne.homedns.org/> or
      <http://gagne.homedns.org/~tgagne/> for more great reading.

I'm playing around some more.

What's weird is the call to mysql_num_rows has the incorrect value for
res, but subsequent #ensure: block's call to mysql_free_result() has the
correct value.

Is there a way to debug through the C callout?

--
Visit <http://tggagne.blogspot.com/>,<http://gagne.homedns.org/> or
      <http://gagne.homedns.org/~tgagne/> for more great reading.

stmt_fetch_row() really doesn't like the buffers we send in to bind the
result.  I'll look more closely at how those buffers are constructed in
Smalltalk then sent to mysql_stmt_bind_result().  When a row is fetched
an values are being put into the buffers, the memory is pointing all
over the place.  Actually, it mostly looks uninitialized.

I'm pretty sure this is what's causing my program to crash when
accessing Store.

I'll keep looking.

--
Visit <http://tggagne.blogspot.com/>,<http://gagne.homedns.org/> or
      <http://gagne.homedns.org/~tgagne/> for more great reading.

I think I see what might be happening:

(numBufs := xif mysql_stmt_field_count: self stmt) > 0
        ifTrue: [outputBuffersPointer := xif MYSQL_BIND malloc: numBufs].
    super acquireBuffers.
    numBufs > 0
        ifTrue: [xif mysql_stmt_bind_result: self stmt with: outputBuffersPointer]

The method allocated the bind buffers and saved them into outputBuffersPointer.  "super acquireBuffers" build an collection of MySQLBuffer objects, stores them into rowBuffersHolder, but the data is never described into outputBuffersPointer--leaving its memory uninitialized.

I think it's supposed to be initialized as prescribed in <http://dev.mysql.com/doc/refman/4.1/en/c-api-prepared-statement-datatypes.html>

Am I missing something?

-- 
Visit <http://tggagne.blogspot.com/>,<http://gagne.homedns.org/> or
      <http://gagne.homedns.org/~tgagne/> for more great reading.

I'm testing whether or not the only difference is replacing #malloc: w/
#calloc:.  So far, that minor change has allowed me to publish to a
local MySQL database.

Thomas Gagné wrote: --
Visit <http://tggagne.blogspot.com/>,<http://gagne.homedns.org/> or
      <http://gagne.homedns.org/~tgagne/> for more great reading.