Memory issue with output compression (was Re: [PHP-DEV] 4.1.0)

From: Date: Sat, 10 Nov 2001 15:57:40 +0000
Subject: Memory issue with output compression (was Re: [PHP-DEV] 4.1.0)
References: 1 2  Groups: php.dev 
Request: Send a blank email to php-dev+get-69993@lists.php.net to get a copy of this message
After some more investigation, it *might* be related to a bug that existed in 4.0.7 with multiple levels of internal output buffering, so I may have spoken too soon.  I can't really reproduce it, so I asked Yasuo Ohgaki to take a look at it.  If it's indeed the issue, it's a one line fix that can be MFH'd today, and at any rate, it'll only affect people who use zlib.output_compression, plus the mbstring automatic conversion feature.
Another option is that it may be a bug in the mbstring auto conversion, as there's at least one more bug report that may be related (#13698).  It crashes under both HEAD and 4.1.0RC1 (HEAD requires a more complex script, but the bug is there).

Zeev

At 16:57 10/11/2001, Zeev Suraski wrote:
Rasmus - whatever that issue is, it has not been fixed in HEAD. Zeev At 17:43 10/11/2001, Rasmus Lerdorf wrote:
I think the assumption that the PHP_4_0_7 branch is "pretty stable" and "pretty much ready to go" is the key here. How do you know? I think it is up to the QA team to tell us if this is the case. From what I can see, I don't think this is so. Jani, did you ever resolve that issue you posted about on Oct.24 related to bug #13806? You said it was only reproducable in the branch but fine in HEAD at the time. -Rasmus On Sat, 10 Nov 2001, Zeev Suraski wrote:
Guys, We have a bit of a dilemma here. As you all know, the 4.0.7 branch, on which 4.1.0 is currently scheduled to be based on, has branched away a few months ago. Some people have expressed concern that releasing 4.1.0 based on that branch is not a good idea, because there have been so many changes in the HEAD branch, and synchronizing fixes and so on is going to be a headache. There are basically two options: (a) Go with 4.1.0 based on 4.0.7 the way we originally intended. Pros: It's pretty stable, tested, and pretty much ready to go out the door with minimum extra work. Cons: We get a release out there that is based on code from several months ago, which doesn't contain some bug fixes and changes. (b) Drop the current release branch. Rebranch from HEAD, and release
4.1.0
based on the current CVS. Pros: All of the bug fixes/features go into 4.1.0, we don't release a version based on old code. Cons: Requires a complete new cycle of QA, as lots of key issues changed since we branched. Two major examples that come to mind are the sessions code (trans_sid) and file uploads, which were very significantly changed. My personal opinion is that we should go on with (a), and start the
release
process for 4.2.0, based on the latest CVS, immediately afterwards. I
fear
instability in the new sessions/file upload code too much, and don't want to delay 4.1.0 for much longer. Thies, on the other hand, supports option (b), because he's afraid of having a new release based on several months old CVS is going to be a
headache.
Your comments are quite welcome, let's try to reach consensus as soon
as we
can (wishful thinking? :) Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net


Thread (42 messages)

« previous php.dev (#69993) next »