[asterisk-users] Asterisk Database Handling

[Tilghman Lesher]

On Wednesday 21 May 2008 19:36:11 Steve Prior wrote:
> Tilghman Lesher wrote:
> > Correct; it's actually a workaround for a bug in the MySQL drivers.  It
> > was discovered long after 1.2 was end-of-lifed.
>
> I got bit by MySQL reconnects on some other software I wrote I think when I
> jumped from MySQL 4.* to 5.*.  If memory serves, here is the relevant info
> from the official MySQL documentation:
>
> From: http://dev.mysql.com/doc/refman/5.0/en/upgrading-from-4-1.html
>
> The reconnect flag in the MYSQL structure is set to 0 by
> mysql_real_connect(). Only those client programs which did not explicitly
> set this flag to 0 or 1 after mysql_real_connect()  experience a change.
> Having automatic reconnection enabled by default was considered too
> dangerous (due to the fact that table locks, temporary tables, user
> variables, and session variables are lost after reconnection).
>
>
> This may explain why this is happening in Asterisk.  In the case of my
> other code the answer was not to keep a long term connection through idle
> periods.

No, actually, we're using that flag to try to get automatic reconnection, and
we're getting a segmentation fault from the MySQL drivers.  It would be one
thing if queries simply failed, but that's not the case.  Note also that we're
not only not using any of those items which could be lost after a
reconnection, we're actually re-preparing the statement handle after each
reconnect.

However, once I added the idlecheck timeout, I have yet to have gotten the
segmentation fault related to this MySQL driver bug.

Interestingly, the segfault only happens on the second statement run after
a reconnect, which leads me to believe that there is some shared structure
which is getting properly reallocated in one place, leaving a stale handle to
another, which when dereferenced causes the segmentation fault.  However,
not being familiar with the driver code, I haven't gone any further in trying
to track this bug down.

-- 
Tilghman