Hello,
A data corruption issue has been discovered in the C IO lib in Python 3.1 (http://bugs.python.org/issue6629). I've applied a fix, and I wonder whether we should make a release quickly to minimize the probability of users hitting the problem? (Georg tells me Benjamin is on holiday, however)
Regards
Antoine.
On Thu, Aug 6, 2009 at 14:01, Antoine Pitrou solipsis@pitrou.net wrote:
Hello,
A data corruption issue has been discovered in the C IO lib in Python 3.1 (http://bugs.python.org/issue6629). I've applied a fix, and I wonder whether we should make a release quickly to minimize the probability of users hitting the problem?
Probably, or at least make the patch available directly.
(Georg tells me Benjamin is on holiday, however)
Yeah, I think he is in Sweden. Anyone know when he is due back?
-Brett
A data corruption issue has been discovered in the C IO lib in Python 3.1 (http://bugs.python.org/issue6629). I've applied a fix, and I wonder whether we should make a release quickly to minimize the probability of users hitting the problem?
There are always two dimensions in which to evaluate criticality of an issue: how serious is the problem it can cause when it hits, and in how many real applications is it likely to occur?
In the first dimension, I agree it's a serious problem. In the second dimension, it only affects applications that seek on files, and so I believe the problem is only of minor relevance.
I think posting a patch on the 3.1 release page would be sufficient for now, along with a summary description on the circumstances that may trigger the bug, and the consequences it may cause.
Regards, Martin
Le vendredi 07 août 2009 à 00:02 +0200, "Martin v. Löwis" a écrit :
There are always two dimensions in which to evaluate criticality of an issue: how serious is the problem it can cause when it hits, and in how many real applications is it likely to occur?
In the first dimension, I agree it's a serious problem. In the second dimension, it only affects applications that seek on files, and so I believe the problem is only of minor relevance.
It doesn't depend on seek() actually (this was the reporter's diagnosis, which turned out wrong). It happens when writing more than the buffer size after the buffer was filled for readahead but not entirely consumed.
The fact that it wasn't reported before may have to do with either the fact that it indeed doesn't affect a lot of applications, or that not many people have been using 3.1 "seriously" yet.
As a side note, when I was working on the IO lib, I regularly ran the Durus stress test script in addition to our test suite. So the problem might indeed be unlikely in the real world.
I think posting a patch on the 3.1 release page would be sufficient for now, along with a summary description on the circumstances that may trigger the bug, and the consequences it may cause.
I'm fine with this decision. The patch can be trivially extracted from one of the commits or svnmerges, but I don't know how to post it on the release page.
Regards
Antoine.
PS : Obviously, having our own brand new IO subsystem rather than relying on a venerable standard C library is not without risks.
Antoine Pitrou schrieb:
Hello,
A data corruption issue has been discovered in the C IO lib in Python 3.1 (http://bugs.python.org/issue6629). I've applied a fix, and I wonder whether we should make a release quickly to minimize the probability of users hitting the problem? (Georg tells me Benjamin is on holiday, however)
FWIW, I also think we should make a new micro release right now. We can't be seen to take data corruption issues with the most basic file operations lightly, especially in Python 3; otherwise, people will think we still don't consider it ready for use.
We can either make a release with only that patch applied, or a release of the full 3.1-maint branch, but the latter would need alphas and betas.
Georg
-- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Thu, Aug 6, 2009 at 4:28 PM, Georg Brandlg.brandl@gmx.net wrote:
Antoine Pitrou schrieb:
Hello,
A data corruption issue has been discovered in the C IO lib in Python 3.1 (http://bugs.python.org/issue6629). I've applied a fix, and I wonder whether we should make a release quickly to minimize the probability of users hitting the problem? (Georg tells me Benjamin is on holiday, however)
FWIW, I also think we should make a new micro release right now. We can't be seen to take data corruption issues with the most basic file operations lightly, especially in Python 3; otherwise, people will think we still don't consider it ready for use.
We can either make a release with only that patch applied, or a release of the full 3.1-maint branch, but the latter would need alphas and betas.
+1
Georg
-- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Thu, Aug 6, 2009 at 16:42, Guido van Rossum guido@python.org wrote:
On Thu, Aug 6, 2009 at 4:28 PM, Georg Brandlg.brandl@gmx.net wrote:
Antoine Pitrou schrieb:
Hello,
A data corruption issue has been discovered in the C IO lib in Python 3.1 (http://bugs.python.org/issue6629). I've applied a fix, and I wonder whether we should make a release quickly to minimize the probability of users hitting the problem? (Georg tells me Benjamin is on holiday, however)
FWIW, I also think we should make a new micro release right now. We can't be seen to take data corruption issues with the most basic file operations lightly, especially in Python 3; otherwise, people will think we still don't consider it ready for use.
We can either make a release with only that patch applied, or a release of the full 3.1-maint branch, but the latter would need alphas and betas.
+1
Is that for the former or latter solution? Assuming the former, who is going to organize this since Benjamin is on vacation? And do we want just a source release or a full binary release (I assume the latter but the former is a lot easier)?
-Brett
On Thu, Aug 6, 2009 at 5:42 PM, Brett Cannonbrett@python.org wrote:
On Thu, Aug 6, 2009 at 16:42, Guido van Rossum guido@python.org wrote:
On Thu, Aug 6, 2009 at 4:28 PM, Georg Brandlg.brandl@gmx.net wrote:
Antoine Pitrou schrieb:
Hello,
A data corruption issue has been discovered in the C IO lib in Python 3.1 (http://bugs.python.org/issue6629). I've applied a fix, and I wonder whether we should make a release quickly to minimize the probability of users hitting the problem? (Georg tells me Benjamin is on holiday, however)
FWIW, I also think we should make a new micro release right now. We can't be seen to take data corruption issues with the most basic file operations lightly, especially in Python 3; otherwise, people will think we still don't consider it ready for use.
We can either make a release with only that patch applied, or a release of the full 3.1-maint branch, but the latter would need alphas and betas.
+1
Is that for the former or latter solution? Assuming the former, who is going to organize this since Benjamin is on vacation? And do we want just a source release or a full binary release (I assume the latter but the former is a lot easier)?
I just meant to +1 the "we need to make a new micro-release right now" paragraph. Logistically, I think it needs to be a full binary release but it could be identical to 3.1 except for the one patch. Hopefully that obviates the need for alphas and betas. Who? Not me :-(
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
I just meant to +1 the "we need to make a new micro-release right now" paragraph. Logistically, I think it needs to be a full binary release but it could be identical to 3.1 except for the one patch.
Looking at Misc/NEWS, there are a number of worthy bugfixes already in. Why not just do a regular micro-release, reflecting the state of release31-maint? We could stick to the normal procedures -- the only thing different is that we're doing it sooner than planned.
Raymond
Le jeudi 06 août 2009 à 23:32 -0700, Raymond Hettinger a écrit :
I just meant to +1 the "we need to make a new micro-release right now" paragraph. Logistically, I think it needs to be a full binary release but it could be identical to 3.1 except for the one patch.
Looking at Misc/NEWS, there are a number of worthy bugfixes already in.
Indeed, a couple of which could be considered serious:
Issue #6573: set.union() stopped processing inputs if an instance of self occurred in the argument chain.
Issue #6415: Fixed warnings.warn segfault on bad formatted string.
Issue #6344: Fixed a crash of mmap.read() when passed a negative argument.
As a sidenote: I'm a relatively young core developer here, are there any precedents of such critical bugs? How has the situation been handled then?
Regards
Antoine.
Antoine Pitrou schrieb:
Le jeudi 06 août 2009 à 23:32 -0700, Raymond Hettinger a écrit :
I just meant to +1 the "we need to make a new micro-release right now" paragraph. Logistically, I think it needs to be a full binary release but it could be identical to 3.1 except for the one patch.
Looking at Misc/NEWS, there are a number of worthy bugfixes already in.
Indeed, a couple of which could be considered serious:
Issue #6573: set.union() stopped processing inputs if an instance of self occurred in the argument chain.
Issue #6415: Fixed warnings.warn segfault on bad formatted string.
Issue #6344: Fixed a crash of mmap.read() when passed a negative argument.
Less serious, but a showstopper nevertheless: #6126, which basically renders pdb unusable. I'll try to remember to commit the fix as soon as SVN is back.
Georg
-- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Thu, Aug 6, 2009 at 8:28 PM, Georg Brandlg.brandl@gmx.net wrote:
FWIW, I also think we should make a new micro release right now. We can't be seen to take data corruption issues with the most basic file operations lightly, especially in Python 3; otherwise, people will think we still don't consider it ready for use.
+1
-- . Facundo
Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
On Thu, Aug 6, 2009 at 7:28 PM, Georg Brandlg.brandl@gmx.net wrote:
Antoine Pitrou schrieb:
Hello,
A data corruption issue has been discovered in the C IO lib in Python 3.1 (http://bugs.python.org/issue6629). I've applied a fix, and I wonder whether we should make a release quickly to minimize the probability of users hitting the problem? (Georg tells me Benjamin is on holiday, however)
FWIW, I also think we should make a new micro release right now. We can't be seen to take data corruption issues with the most basic file operations lightly, especially in Python 3; otherwise, people will think we still don't consider it ready for use.
+1 for a micro release.
-- Alexandre
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Georg Brandl wrote:
A data corruption issue has been discovered in the C IO lib in Python 3.1 (http://bugs.python.org/issue6629). I've applied a fix, and I wonder whether we should make a release quickly to minimize the probability of users hitting the problem? (Georg tells me Benjamin is on holiday, however)
FWIW, I also think we should make a new micro release right now. We can't be seen to take data corruption issues with the most basic file operations lightly, especially in Python 3; otherwise, people will think we still don't consider it ready for use.
+1. Messing with people files is probably the worst you can do.
Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQCVAwUBSnuNL5lgi5GaxT1NAQIamQP+ItacvhX2myXmQ0uFtxHuL+2HxIZpjiPG zC/32QMeSuYEWERzfmADUyePeXMuN6pBQmkkbV5g0NQyQfkdKUqa7qzpeGAwSh5x SY30rP2K2gIi7egJd+1Akemm9HHvMepPip4YiLedGaY4naIQgGm2BHnOIpJcsgwY szLLo6jdn/M= =j0jo -----END PGP SIGNATURE-----
Hi everyone, I'm just getting back from the nice trip to the Olympic Peninsula. I should be able to do a release sometime next week. In the meantime, could someone post the patch to the 3.1 download site? (We should add a note to the quick links section, too.)
2009/8/6 Georg Brandl g.brandl@gmx.net:
We can either make a release with only that patch applied, or a release of the full 3.1-maint branch, but the latter would need alphas and betas.
Why does that require doing alphas and betas? I believe the 2.5.x releases only had a RC and the 3.0.1 and 2.6.x had no preview releases before the final bugfix release.
-- Regards, Benjamin
I have in the past done a microrelease without a release candidate. It didn't go well.
On Fri, Aug 7, 2009 at 1:22 PM, Benjamin Peterson benjamin@python.orgwrote:
Hi everyone, I'm just getting back from the nice trip to the Olympic Peninsula. I should be able to do a release sometime next week. In the meantime, could someone post the patch to the 3.1 download site? (We should add a note to the quick links section, too.)
2009/8/6 Georg Brandl g.brandl@gmx.net:
We can either make a release with only that patch applied, or a release of the full 3.1-maint branch, but the latter would need alphas and betas.
Why does that require doing alphas and betas? I believe the 2.5.x releases only had a RC and the 3.0.1 and 2.6.x had no preview releases before the final bugfix release.
-- Regards, Benjamin
python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Benjamin Peterson schrieb:
Hi everyone, I'm just getting back from the nice trip to the Olympic Peninsula. I should be able to do a release sometime next week.
Just at the right time! :)
In the meantime, could someone post the patch to the 3.1 download site? (We should add a note to the quick links section, too.)
2009/8/6 Georg Brandl g.brandl@gmx.net:
We can either make a release with only that patch applied, or a release of the full 3.1-maint branch, but the latter would need alphas and betas.
Why does that require doing alphas and betas? I believe the 2.5.x releases only had a RC and the 3.0.1 and 2.6.x had no preview releases before the final bugfix release.
OK, maybe alphas and betas were a bit too skeptical; but there needs to be *something* that people can test before final. Otherwise, another release may be necessary just afterwards :|
Georg
-- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
Georg Brandl wrote:
OK, maybe alphas and betas were a bit too skeptical; but there needs to be *something* that people can test before final. Otherwise, another release may be necessary just afterwards :|
As has been noted, release candidate -> maintenance release is the approach that has worked well in the past. Only including bug fixes means the alpha/beta stages aren't needed, but going through an RC makes sure the installers and the like are all in a happy state as well.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Its also about preventing the brown paper bag releases caused by stupid screwups.
On Aug 7, 2009 8:08 PM, "Nick Coghlan" ncoghlan@gmail.com wrote:
Georg Brandl wrote: > OK, maybe alphas and betas were a bit too skeptical; but there needs to be > *... As has been noted, release candidate -> maintenance release is the approach that has worked well in the past. Only including bug fixes means the alpha/beta stages aren't needed, but going through an RC makes sure the installers and the like are all in a happy state as well.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
_______________________________________________ python-committers mailing list python-committers@pyt...
On Aug 7, 2009, at 2:20 AM, Georg Brandl wrote:
Why does that require doing alphas and betas? I believe the 2.5.x releases only had a RC and the 3.0.1 and 2.6.x had no preview
releases before the final bugfix release.OK, maybe alphas and betas were a bit too skeptical; but there needs
to be *something* that people can test before final. Otherwise, another
release may be necessary just afterwards :|
I'm skeptical about pre-releases for micro releases. Nobody outside
dedicated insiders really tests them and y'all can test the source
branches anyway. I also don't think it's /that/ big of a deal to
release a new micro release right away for the occasional brown bag
moment.
An alternative may be to embargo a micro release from the public for a
day or so. Build it and upload it, and announce it here. Let people
at least test installs and a few very simple things, and then 24 hours
later, update the public links and make the announcement.
OTOH, if and when snakebite.org is part of our normal development
process, the RM can just use that to make sure nothing horrible is
broken.
I'd say JFDI :)
-Barry
participants (13)
-
"Martin v. Löwis" -
Alexandre Vassalotti -
Anthony Baxter -
Antoine Pitrou -
Barry Warsaw -
Benjamin Peterson -
Brett Cannon -
Facundo Batista -
Georg Brandl -
Guido van Rossum -
Jesus Cea -
Nick Coghlan -
Raymond Hettinger