See below for upstream's response. If it's fine with you, we'll also
include this change in our upload:
| Index: mod_wsgi.c
| ===================================================================
| --- mod_wsgi.c (wersja 1351)
| +++ mod_wsgi.c (wersja 1352)
| @@ -1540,7 +1540,6 @@
|
| if (n == -1) {
| PyErr_SetString(PyExc_IOError, "request data read error");
| - Py_DECREF(result);
| return NULL;
| }
(Graham mentions it in his mail)
[Graham Dumpleton, 2009-08-28]
> 2009/8/28 Piotr Ożarowski <pi...@debian.org>:
> > [Bernd Zeimetz, 2009-08-28]
> >> Hi Graham,
> >>
> >> I'm forwarding you a mail from our Debian release managers - could you
> >> give a
> >> comment on that?
> >
> > /me is pretty sure it's a fix, but lets wait for Graham's response :)
> >
> > [...]
> >
> >
> > that's in mod_wsgi.c, btw:
> >> @@ -3538,7 +3583,7 @@
> >> }
> >> }
> >>
> >> - Py_INCREF(m);
> >> + Py_XDECREF(m);
> >>
> >> Py_INCREF(h);
> >>
> >> This appears to be part of upstream r1244
> >> (http://code.google.com/p/modwsgi/source/detail?r=1244&path=/trunk/mod_wsgi/mod_wsgi.c)
> >> for which the commit message is "Protect against decrementing reference
> >> count on
> >> NULL pointer". The other two hunks of the commit do exactly that,
> >> exchanging
> >> Py_DECREF for Py_XDECREF, but replacing Py_INCREF with Py_XDECREF doesn't
> >> seem
> >> to make a lot of sense.
>
> The original code, where it was doing:
>
> Py_INCREF(m);
>
> could technically cause a one off Python object memory leak as it
> should have been decrementing instead of incrementing.
>
> In the greater scheme of things it didn't matter though as it would
> only cause a leak if the Python interpreter was destroyed within that
> process and then reinitialised. For the process this was done in, that
> never occurs as once Python interpreter is destroyed the process is
> exited.
>
> So, fixing a technical mistake in handling object reference counts,
> but change is ultimately of no significance as wasn't causing a
> problem.
>
> The other changes in that change revision were again more
> technicalities, as the thing on which reference count was being
> decremented should always exist. If it didn't then Python would likely
> have crashed before that point. So, again just making code technically
> correct and not actually addressing a presenting problem.
>
> Given this is a fix from mod_wsgi 2.4 and you are looking at getting
> 2.5 into stable tree, is this just someone reviewing the changes.
>
> BTW, I have pending changes for mod_wsgi 2.6 as well. These are detailed at:
>
> http://code.google.com/p/modwsgi/wiki/ChangesInVersion0206
>
> There is though only one in there of any significance, ie., causes a
> crash. This is:
>
> 3. Fixed bug where was decrementing Python object reference count on
> NULL pointer, causing a crash. This was possibly only occuring in
> embedded mode and only where closure of remote client connection was
> detected before any request content was read. The issue may have been
> more prevalent for a HTTPS connection from client.
>
> The code change is a one line change at line 1543 in:
>
> http://code.google.com/p/modwsgi/source/diff?spec=svn1351&r=1352&format=side&path=/branches/mod_wsgi-2.X/mod_wsgi.c
>
> If you look through that functions code you will see that result is
> never set before that point. Don't know what your attitude is to back
> porting obvious fixes from future versions.
>
> I'll be releasing mod_wsgi 2.6 sometime soon, but when really depends
> on when I sort out Python 3.X changes for mod_wsgi 3.0 and am ready
> for that to also go out. Of course, mod_wsgi 2.6 still has to go
> through the whole unstable, testing cycle etc.
>
> Graham
--
-=[ Piotr Ożarowski ]=-
-=[ http://www.ozarowski.pl ]=-
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
