oqgraph-dev team mailing list archive

[Heinz Wiesinger <HMWiesinger@xxxxxxxxxxx>]

On Wednesday 18 June 2014 18:33:59 Andrew McDonnell wrote:
> From a very cursory look at federated it seems we dont have
> `handler::disconnect()` so I'll probably start there. Meantime in the
> medium term I think refactoring ha_oqgraph.cc to look more like
> ha_federated would be a worthwhile activity
> Arjen Lentz <arjen@xxxxxxxxxxxxxxxx> wrote:
> >Hi Andrew, Antony
> >
> >(specifically cc'ing Antony on the email as his email clients might blip
> >for that ;-)
> >
> >Does the graph share object potentially keep a reference to multiple
> >THDs, or only one? If only one, that'd be faulty as of course it can be
> >multiple.
> >
> >Then, I'm not sure THD is the thing that it should tally - using a
> >pointer as a reference can easily end up dangling loose in this way.
> >
> >Does a graph share object need to know exactly what its referenced by,
> >or is the issue simply that it needs to know when to self-destruct?
> >If the latter, then a simple reference count would suffice.
> >
> >You may need some advice on how to ensure that when a connection closes,
> >things get cleaned up properly. We may have missed a hook of some sort.
> >You could also check this in another engine. Perhaps Federated, or
> >Spider, or CONNECT ?
> >
> >Regards,
> >Arjen.
> >
> >On 17/06/14 22:08, Andrew McDonnell wrote:
> >> Hi all,
> >> 
> >> https://mariadb.atlassian.net/browse/MDEV-6282 is a use after free bug
> >> that
> >> happens when one connection is opened, oqgraph queried, then the
> >> connection
> >> closed, then a second connection opened and oqgraph queried again in the
> >> same server session.
> >> 
> >> Essentially, our handler in open() eventually creates a graph share
> >> object
> >> that keeps a reference to the underlying TABLE object, this table object
> >> has an in_use field that is a THD*.
> >> 
> >> But when the connection goes away, mysqld free()'d that THD.  Except the
> >> handler never processes close() at this point, and we never get a chance
> >> to
> >> cause that table object to 'refresh' for want of a better word.
> >> 
> >> Which means when the next query comes along, eventually it calls
> >> index_read() on our handler which calls seek_to() in the graph code
> >> which calls back into mysql using ha_index_read_map on the backing
> >> table, which then crashes because it eventually calls
> >> increment_statistics which first increments free()'d memory via &SSV and
> >> then accesses a bogus member pointer in the long dead THD.
> >> 
> >> I dont yet know enough about the internals of mysqld to know how to
> >> handle this...

Hey guys!

It's been a while since I heard anything about this so I was wondering what 
the status is. Any news?

Grs,
Heinz

Attachment: signature.asc
Description: This is a digitally signed message part.