If it crashes in mysql_store_result(), the probability of it being a bug in MySQLdb is vanishingly small, and you are probably looking at a bug in MySQL itself.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
--->>>> _mysql.pyd!_mysql_ResultObject_Initialize(_mysql_ResultObject * self=0x11b926f0, _object * args=0x00b647d8, _object * kwargs=0x11edaf60) Line 384 + 0xd C
_mysql.pyd!_mysql_ConnectionObject_store_result(_mysql_ConnectionObject * self=0x11b61900, _object * args=0x00961030) Line 1925 + 0x8 C
python24.dll!1e079bb7()
python24.dll!1e02722f()
python24.dll!1e028ca8()
So I'm pretty sure that means we've a problem in mysqldb. If mysql is acting wrong and sending an ugly value back, mysqldb ought to be robust enough to handle whatever it gets, right?
So in the typical crash we die here:
Py_BEGIN_ALLOW_THREADS ;
if (use)
result = mysql_use_result(&(conn->connection));
else
result = mysql_store_result(&(conn->connection)); <---- die here
self->result = result;
Py_END_ALLOW_THREADS ;
if (!result) {
net {vio=0x00000000 buff=0x00000000 <Bad Ptr> buff_end=0x0315b098 "$±)±þ{" ...} st_net
connector_fd 0x00000000 <Bad Ptr> char *
host 0x0252f980 "localhost" char *
Now could that mean have some kind of freeing/initialization race condition? Also notice, connector_fd is null. Is that normal at this point in the code.
At any rate, can you suggest a "if connection is null, do something else" type fix? Thanks! :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is no "ugly value" being passed back to MySQLdb.
_mysql_ResultObject_Initialize() is being called by _mysql_ConnectionObject_store_result(), which does a check_connection(self) prior to creating the Result object. check_connection() is a macro:
define check_connection(c) if (!(c->open)) return _mysql_Exception(c)
Add a check_connection(conn) early in that function (around line 377). If the connection is being nulled prior to this point, this should prevent the crash, or maybe make it crash earlier. However I strongly suspect it is happening in the call to mysql_store_result().
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
mysqldb--> _mysql.pyd!_mysql_ResultObject_Initialize(_mysql_ResultObject * self=0x11b903f0, _object * args=0x00b647d8, _object * kwargs=0x11cccb70) Line 389 + 0xd C
_mysql.pyd!_mysql_ConnectionObject_store_result(_mysql_ConnectionObject * self=0x11e9e3a0, _object * args=0x00961030) Line 1930 + 0x8 C
python24.dll!1e079bb7()
python24.dll!1e02722f()
I'm going out on a limb here and guessing: Is it now possible that conn->connection is not null at the time of the check, but becomes null while we're inside the mysql func (mysql_store_result)? I'm guess the problem is still inside of mysqldb, and not mysql_client code, but I can't be 100% sure.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yep, as I stated in a different post (which is now gone ... ??) adding a check around line 377 does help a bit. My code is able to run longer and faster before crashing, but still we crash:
> _mysql.pyd!_net_real_write() + 0x267 C++
_mysql.pyd!_my_net_read() + 0x1b C++
_mysql.pyd!_cli_safe_read() + 0x16 C
_mysql.pyd!_cli_read_rows() + 0x1df C
_mysql.pyd!_mysql_store_result@4() + 0xcd C
_mysql.pyd!_mysql_ResultObject_Initialize(_mysql_ResultObject * self=0x1318bfc0, _object * args=0x11a6e058, _object * kwargs=0x207e1ed0) Line 395 + 0xd C
_mysql.pyd!_mysql_ConnectionObject_store_result(_mysql_ConnectionObject * self=0x142e9b90, _object * args=0x00961030) Line 1937 + 0x8 C
python24.dll!1e079bb7()
I'll try to get in touch with someone at mysql since you believe that is where the problem lies. Can you think of anything else that might be helpful?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'll be trying to hunt down this bug. Here are three sample crashes from the three runs I just did:
self->use = use;
Py_BEGIN_ALLOW_THREADS ;
if (use)
result = mysql_use_result(&(conn->connection));
else
result = mysql_store_result(&(conn->connection)); <--crash and burn!
self->result = result;
Py_END_ALLOW_THREADS ;
if (!result) {
self->converter = PyTuple_New(0);
return 0;
}
n = mysql_num_fields(result);
self->nfields = n;
EAX = 00000000 EBX = 000006F2 ECX = 00002714 EDX = 000F0001
ESI = 11A99738 EDI = 031434B9 EIP = 0239E7A7 ESP = 037CF4F8
EBP = 00000281 EFL = 00000286
00000088 = ????????
--> _mysql.pyd!_mysql_ResultObject_Initialize(_mysql_ResultObject * self=0x119d7ed0, _object * args=0x01f4a580, _object * kwargs= 0x11edc810) Line 384 + 0xd C
_mysql.pyd!_mysql_ConnectionObject_store_result(_mysql_ConnectionObject * self=0x11a99730, _object * args=0x00961030) Line 1925 + 0x8 C
python24.dll!1e079bb7()
python24.dll!1e02722f()
python24.dll!1e028ca8()
python24.dll!1e028ff4()
ntdll.dll!7c91056d()
python24.dll!1e02608b()
python24.dll!1e0272a6()
python24.dll!1e028ff4()
_mysql_ConnectionObject_query(
_mysql_ConnectionObject self,
PyObject args)
{
char *query;
int len, r;
if (!PyArg_ParseTuple(args, "s#:query", &query, &len)) return NULL;
check_connection(self);
Py_BEGIN_ALLOW_THREADS
r = mysql_real_query(&(self->connection), query, len);
Py_END_ALLOW_THREADS <-----------crash and burn
if (r) return _mysql_Exception(self);
Py_INCREF(Py_None);
return Py_None;
}
EAX = 00000000 EBX = FFFFFFFF ECX = 00000000 EDX = 00000004
ESI = 11E51B30 EDI = 0314304C EIP = 0239E71D ESP = 030FF6C4
EBP = 00000000 EFL = 00000246
--> _mysql.pyd!_mysql_ConnectionObject_query(_mysql_ConnectionObject * self=0x11e51b28, _object * args=0x11ad9d90) Line 1820 C
python24.dll!1e079bb7()
EAX = 00000000 EBX = 000006F2 ECX = 00002714 EDX = 002D0001
ESI = 11E85128 EDI = 03D235D6 EIP = 0239E7A7 ESP = 0374F4F8
EBP = 00000164 EFL = 00000286
00000088 = ????????
--> _mysql.pyd!_mysql_ResultObject_Initialize(_mysql_ResultObject * self=0x11a87210, _object * args= 0x11a6d0d0, _object * kwargs=0x11ba4a50) Line 384 + 0xd C
_mysql.pyd!_mysql_ConnectionObject_store_result(_mysql_ConnectionObject * self=0x11e85120, _object * args=0x00961030) Line 1925 + 0x8 C
python24.dll!1e079bb7()
python24.dll!1e02722f()
Oh, here is the debug version if the mysql_client stuff:
if ((int) (length=vio_read(net->vio,(char*) pos,remain)) <= 0L)
{
my_bool interrupted = vio_should_retry(net->vio); <------------ crash
#if (!defined(WIN) && !defined(__EMX
fd 976 unsigned int
max_packet 8192 unsigned long
max_packet_size 1073741824 unsigned long
> _mysql.pyd!my_real_read(st_net * net=0x1306f568, unsigned long * complen=0x03a2f4fc) Line 811 + 0xb C++
_mysql.pyd!my_net_read(st_net * net=0x1306f568) Line 983 + 0xd C++
_mysql.pyd!cli_safe_read(st_mysql * mysql=0x1306f568) Line 596 + 0x9 C
_mysql.pyd!cli_read_rows(st_mysql * mysql=0x1306f568, st_mysql_field * mysql_fields=0x031b51f8, unsigned int fields=34) Line 1355 + 0x9 C
_mysql.pyd!mysql_store_result(st_mysql * mysql=0x1306f568) Line 2738 + 0x24 C
_mysql.pyd!_mysql_ResultObject_Initialize(_mysql_ResultObject * self=0x12f66ba0, _object * args=0x00b64828, _object * kwargs=0x11ae3660) Line 392 + 0x5 C
_mysql.pyd!_mysql_ConnectionObject_store_result(_mysql_ConnectionObject * self=0x1306f560, _object * args=0x00961030) Line 1934 + 0x8 C
python24.dll!1e079bb7()
python24.dll!1e02722f()
python24.dll!1e028ca8()
python24.dll!1e028ff4()
_mysql.pyd!unpack_fields(st_mysql_data * data=0x03a2f718, st_mem_root * alloc=0x00000000, unsigned int fields=1, char default_value='', unsigned int server_capabilities=10777944) Line 1272 + 0x16 C
python24.dll!1e028ff4()
python24.dll!1e0253ed()
python24.dll!1e02608b()
python24.dll!1e0272a6()
python24.dll!1e028ff4()
python24.dll!1e02608b()
python24.dll!1e0272a6()
python24.dll!1e028ff4()
python24.dll!1e02608b()
python24.dll!1e0272a6()
python24.dll!1e028ff4()
python24.dll!1e0299a9()
python24.dll!1e02a01c()
python24.dll!1e0260e6()
python24.dll!1e0272a6()
python24.dll!1e028ff4()
python24.dll!1e02608b()
python24.dll!1e0272a6()
python24.dll!1e028ff4()
python24.dll!1e05e079()
python24.dll!1e02608b()
python24.dll!1e0272a6()
python24.dll!1e028ff4()
python24.dll!1e05e079()
python24.dll!1e02608b()
python24.dll!1e0272a6()
python24.dll!1e028ff4()
python24.dll!1e0299a9()
python24.dll!1e02a01c()
python24.dll!1e05f35f()
python24.dll!1e018f3c()
python24.dll!1e02cf24()
ntdll.dll!7c90d625()
ntdll.dll!7c90eacf()
ntdll.dll!7c9105c8()
wxmsw272h_core_vc.dll!012bfffc()
ntdll.dll!7c9105c8()
ntdll.dll!7c910551()
ntdll.dll!7c91056d()
kernel32.dll!7c80261a()
kernel32.dll!7c8025f0()
kernel32.dll!7c8025f0()
kernel32.dll!7c802532()
python24.dll!1e018f3c()
python24.dll!1e025eda()
python24.dll!1e0a65e7()
python24.dll!1e0a5f59()
msvcr71.dll!7c34940f()
kernel32.dll!7c80b683()
If it crashes in mysql_store_result(), the probability of it being a bug in MySQLdb is vanishingly small, and you are probably looking at a bug in MySQL itself.
Hmmm ... I'm not so sure about that. Python dies in _mysql.pyd:
--->>>> _mysql.pyd!_mysql_ResultObject_Initialize(_mysql_ResultObject * self=0x11b926f0, _object * args=0x00b647d8, _object * kwargs=0x11edaf60) Line 384 + 0xd C
_mysql.pyd!_mysql_ConnectionObject_store_result(_mysql_ConnectionObject * self=0x11b61900, _object * args=0x00961030) Line 1925 + 0x8 C
python24.dll!1e079bb7()
python24.dll!1e02722f()
python24.dll!1e028ca8()
So I'm pretty sure that means we've a problem in mysqldb. If mysql is acting wrong and sending an ugly value back, mysqldb ought to be robust enough to handle whatever it gets, right?
So in the typical crash we die here:
Py_BEGIN_ALLOW_THREADS ;
if (use)
result = mysql_use_result(&(conn->connection));
else
result = mysql_store_result(&(conn->connection)); <---- die here
self->result = result;
Py_END_ALLOW_THREADS ;
if (!result) {
We die because connection is null:
ob_refcnt 8 int
Now could that mean have some kind of freeing/initialization race condition? Also notice, connector_fd is null. Is that normal at this point in the code.
At any rate, can you suggest a "if connection is null, do something else" type fix? Thanks! :)
There is no "ugly value" being passed back to MySQLdb.
_mysql_ResultObject_Initialize() is being called by _mysql_ConnectionObject_store_result(), which does a check_connection(self) prior to creating the Result object. check_connection() is a macro:
define check_connection(c) if (!(c->open)) return _mysql_Exception(c)
Add a check_connection(conn) early in that function (around line 377). If the connection is being nulled prior to this point, this should prevent the crash, or maybe make it crash earlier. However I strongly suspect it is happening in the call to mysql_store_result().
Trying to fix.
I added this:
The check I added seem to help a lot. My code as able to run longer and faster before it died. But die it did at almost the same spot:
mysqldb--> _mysql.pyd!_mysql_ResultObject_Initialize(_mysql_ResultObject * self=0x11b903f0, _object * args=0x00b647d8, _object * kwargs=0x11cccb70) Line 389 + 0xd C
_mysql.pyd!_mysql_ConnectionObject_store_result(_mysql_ConnectionObject * self=0x11e9e3a0, _object * args=0x00961030) Line 1930 + 0x8 C
python24.dll!1e079bb7()
python24.dll!1e02722f()
I'm going out on a limb here and guessing: Is it now possible that conn->connection is not null at the time of the check, but becomes null while we're inside the mysql func (mysql_store_result)? I'm guess the problem is still inside of mysqldb, and not mysql_client code, but I can't be 100% sure.
Yep, as I stated in a different post (which is now gone ... ??) adding a check around line 377 does help a bit. My code is able to run longer and faster before crashing, but still we crash:
> _mysql.pyd!_net_real_write() + 0x267 C++
_mysql.pyd!_my_net_read() + 0x1b C++
_mysql.pyd!_cli_safe_read() + 0x16 C
_mysql.pyd!_cli_read_rows() + 0x1df C
_mysql.pyd!_mysql_store_result@4() + 0xcd C
_mysql.pyd!_mysql_ResultObject_Initialize(_mysql_ResultObject * self=0x1318bfc0, _object * args=0x11a6e058, _object * kwargs=0x207e1ed0) Line 395 + 0xd C
_mysql.pyd!_mysql_ConnectionObject_store_result(_mysql_ConnectionObject * self=0x142e9b90, _object * args=0x00961030) Line 1937 + 0x8 C
python24.dll!1e079bb7()
I'll try to get in touch with someone at mysql since you believe that is where the problem lies. Can you think of anything else that might be helpful?