gnue-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnue-dev] Fw: [ mysql-python-Bugs-536260 ] Problem with fetchmany


From: Harald Meyer
Subject: [Gnue-dev] Fw: [ mysql-python-Bugs-536260 ] Problem with fetchmany
Date: Sat, 27 Apr 2002 08:54:49 +0200

This might be of interest. I reported that problem to the mysqldb guys
and it seems that they are arguing whether this is a mysqldb fault or a
gnue fault, because we call fetchmany without doing this check.

Harald Meyer

----- Original Message -----
From: <address@hidden>
To: <address@hidden>
Sent: Saturday, April 27, 2002 1:44 AM
Subject: [ mysql-python-Bugs-536260 ] Problem with fetchmany


> Bugs item #536260, was opened at 2002-03-28 09:06
> You can respond by visiting:
>
http://sourceforge.net/tracker/?func=detail&atid=374932&aid=536260&grou
p_id=22307
>
> Category: MySQLdb
> Group: None
> Status: Open
> Resolution: None
> Priority: 5
> Submitted By: Nobody/Anonymous (nobody)
> Assigned to: Andy Dustman (adustman)
> Summary: Problem with fetchmany
>
> Initial Comment:
> If fetchmany in cursors.py is called with no
> parameters, mysqldb crashes. The Problem seems to be
> the definition of fetchmany:
>
> def fetchmany(self, size=None)
>
> The size=None gives it a wrong type. If it is replaced
> with size=0 no problem occour.
>
> ---------------------------------------------------------------------
-
>
> >Comment By: Andy Dustman (adustman)
> Date: 2002-04-26 18:44
>
> Message:
> Logged In: YES
> user_id=71372
>
> No, I don't think so. _mysql_ResultObject_fetch_row() cannot
> be passed a None because of this:
>
> if (!PyArg_ParseTupleAndKeywords(args, kwargs,
> "|ii:fetch_row", kwlist,
> &maxrows, &how))
>
> The format code only allows for an integer. If maxrows is
> non-zero, the section of code you quote cannot be reached;
> instead:
>
> if (maxrows) {
> if (!(r = PyTuple_New(maxrows))) goto error;
> rowsadded = _mysql__fetch_row(self, &r, skiprows, maxrows,
> convert_row);
> if (rowsadded == -1) goto error;
> } else { ...
>
> In fact, the section of code you quote is only reachable if
> a non-standard cursor class is used (one with
> CursorUseMixIn). I am starting to think there *is* a problem
> there, however, but not because of the condition. Basically
> that condition is saying, if we didn't get all the rows we
> requested, we're done. Otherwise, there may be more rows to
> fetch. But what I think I need after that statement is
> something like this:
>
> #if PY_VERSION_HEX < 0x02020000
> if (_PyTuple_Resize(r, skiprows+maxrows, 0) == -1) goto error;
> #else
> if (_PyTuple_Resize(r, skiprows+maxrows) == -1) goto error;
> #endif
>
> because more space needs to be allocated prior to calling
> _mysql__fetch_row() again. I'd appreciate it if you tested
> this fix (add it immediately after the if (rowsadded <
> maxrows) break; line). Even so, this seems to be a pretty
> hard thing to trigger. You have to use a SSCursor, call
> cursor.fetchmany(0) or cursor.fetchall() (they both
> ultimately call _mysql_ResultObject_fetch_row), and then
> have at least 1000 rows in the result set.
>
> ---------------------------------------------------------------------
-
>
> Comment By: Danny Yoo (dyoo)
> Date: 2002-04-26 18:29
>
> Message:
> Logged In: YES
> user_id=49843
>
> Fixed, I think.  See patch:
>
>
http://sourceforge.net/tracker/index.php?func=detail&aid=549301&group_i
d=22307&$
>
>
> Hope this helps!
>
> ---------------------------------------------------------------------
-
>
> Comment By: Danny Yoo (dyoo)
> Date: 2002-04-26 17:35
>
> Message:
> Logged In: YES
> user_id=49843
>
> See bug 549279: I think I figured out what's causing the
> segfaults.  It's a subtle boundary condition in
> _mysql._mysql_ResultObject_fetch_row, around line 850 or so:
>
> if (!(r = PyTuple_New(maxrows))) goto error;
> while (1) {
> rowsadded = _mysql__fetch_row(self, &r, skiprows,
> maxrows, convert_row);
> printf("rowsadded = %d\n", rowsadded); /*debug*/
> if (rowsadded == -1) goto error;
> skiprows += rowsadded;
> if (rowsadded < maxrows) break;
>             ^^^^^^^^^^^^^^^^^^^^
>
> The last statement with "rowsadded < maxrows" is buggy: it
> should be "rowsadded <= maxrows".  Otherwise, we add more
> elements in an already-full tuple, and that'll cause the
> segfault.
>
>
>
> ---------------------------------------------------------------------
-
>
> You can respond by visiting:
>
http://sourceforge.net/tracker/?func=detail&atid=374932&aid=536260&grou
p_id=22307
>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]