# Releasing 4.3.5pl1 - Thread: https://externals.io/message/8859 - Original archive: https://news-web.php.net/php.internals/8859 - Started by Andi Gutmans on 2004-04-01T12:41:17+00:00 - Messages: 9 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #8859 — Andi Gutmans — 2004-04-01T12:41:17+00:00 URL: https://externals.io/message/8859#8859 Hi, A pretty serious bug crept into 4.3.5. A few weeks ago, a TSRM fix was commited which was supposed to prevent memory leaks when PHP ends its execution (shutdown dtor was not being called in tsrm_shutdown()). This fix causes a crash when a shared extension registers a dtor function. This is because the dtor is called after the extension is unloaded. Stas has commited a patch to TSRM which prevents the dtor call for now, which isn't very important because besides giving a warm fuzzy feeling, it's right before PHP shuts down and thus, memory leaks aren't important anyway. On a side note the per-thread dtor is still called, thus, eliminating leaks when threads are created/destroyed in multi-threaded servers. I suggest we release 4.3.5pl1 with just this bug fix within the next couple of days as this is a crash bug which can happen on any MT server or MT-safe PHP builds (such as Windows CGI). Andi --- ## #8860 — Edin Kadribasic — 2004-04-01T12:51:10+00:00 URL: https://externals.io/message/8859#8860 · In reply to: #8859 +1 except I would call it 4.3.6. We have precedent for this sort bug fix release. 4.3.1 if I remember correctly. There were many bug reports regarding some data/time functions, maybe we should merge that fix in as well? Rasmus/Derick should know more about this one,. Edin > Hi, > > A pretty serious bug crept into 4.3.5. > A few weeks ago, a TSRM fix was commited which was supposed to prevent > memory leaks when PHP ends its execution (shutdown dtor was not being > called in tsrm_shutdown()). This fix causes a crash when a shared extension > registers a dtor function. This is because the dtor is called after the > extension is unloaded. Stas has commited a patch to TSRM which prevents the > dtor call for now, which isn't very important because besides giving a warm > fuzzy feeling, it's right before PHP shuts down and thus, memory leaks > aren't important anyway. On a side note the per-thread dtor is still > called, thus, eliminating leaks when threads are created/destroyed in > multi-threaded servers. > I suggest we release 4.3.5pl1 with just this bug fix within the next couple > of days as this is a crash bug which can happen on any MT server or MT-safe > PHP builds (such as Windows CGI). > > Andi --- ## #8861 — Ilia Alshanetsky — 2004-04-01T14:19:13+00:00 URL: https://externals.io/message/8859#8861 · In reply to: #8860 > +1 except I would call it 4.3.6. We have precedent for this sort bug fix > release. 4.3.1 if I remember correctly. +1 > There were many bug reports regarding some data/time functions, maybe we > should merge that fix in as well? Rasmus/Derick should know more about this > one,. If we decide to make 4.3.6 I think we should include this fix as well, as it affects a fairly large number of users as well. Ilia --- ## #8866 — Rasmus Lerdorf — 2004-04-01T17:05:10+00:00 URL: https://externals.io/message/8859#8866 · In reply to: #8861 > > > […] > > +1 > > > […] > > If we decide to make 4.3.6 I think we should include this fix as well, as it > affects a fairly large number of users as well. Yup, given the fact that the DST change date is fast approaching, it would be good to get the mktime/gmmktime fixes out there soon along with the strftime fix. Nothing says we have to wait until we have 100+ bug fixes in there. We have fixed 20 or so bugs since 4.3.5 and I see nothing wrong with pushing out a 4.3.6 with these 20 fixes now. -Rasmus --- ## #8867 — Ilia Alshanetsky — 2004-04-01T17:09:31+00:00 URL: https://externals.io/message/8859#8867 · In reply to: #8866 > Yup, given the fact that the DST change date is fast approaching, it would > be good to get the mktime/gmmktime fixes out there soon along with the > strftime fix. Nothing says we have to wait until we have 100+ bug fixes > in there. We have fixed 20 or so bugs since 4.3.5 and I see nothing wrong > with pushing out a 4.3.6 with these 20 fixes now. While, some fixes are fairly safe, others may raise issues we had not considered (ex. fix for bug #27782). if we are making a quick release without a prior testing (RC) process I'd prefer to have only the absolutely necessary fixes such as DST & TSRM. Ilia --- ## #8868 — Derick Rethans — 2004-04-01T17:19:11+00:00 URL: https://externals.io/message/8859#8868 · In reply to: #8866 > > > > […] > > Yup, given the fact that the DST change date is fast approaching, it would It did already change in Europe, and I'm on the bug now. Should be fixed tonight. > be good to get the mktime/gmmktime fixes out there soon along with the > strftime fix. Nothing says we have to wait until we have 100+ bug fixes > in there. We have fixed 20 or so bugs since 4.3.5 and I see nothing wrong > with pushing out a 4.3.6 with these 20 fixes now. Me neither, the more changes creep in the more we need an RC for this. regards, Derick --- ## #8869 — Rasmus Lerdorf — 2004-04-01T17:25:21+00:00 URL: https://externals.io/message/8859#8869 · In reply to: #8867 > > > […] > > While, some fixes are fairly safe, others may raise issues we had not > considered (ex. fix for bug #27782). if we are making a quick release without > a prior testing (RC) process I'd prefer to have only the absolutely necessary > fixes such as DST & TSRM. I don't think we should push it out without an RC. I just think we should instigate the RC process now rather than waiting. Especially considering the fact that there were some non-trivial changes. The more other changes we add on top of these, the more time we will need for RC. -Rasmus --- ## #8870 — Andrei Zmievski — 2004-04-01T17:40:57+00:00 URL: https://externals.io/message/8859#8870 · In reply to: #8869 > I don't think we should push it out without an RC. I just think we should > instigate the RC process now rather than waiting. Especially considering > the fact that there were some non-trivial changes. The more other changes > we add on top of these, the more time we will need for RC. +1 from me on this.. - Andrei --- ## #8871 — Ilia Alshanetsky — 2004-04-01T17:44:39+00:00 URL: https://externals.io/message/8859#8871 · In reply to: #8869 > I don't think we should push it out without an RC. I just think we should > instigate the RC process now rather than waiting. Especially considering > the fact that there were some non-trivial changes. The more other changes > we add on top of these, the more time we will need for RC. As long as we have RC, +1 from me as well. Ilia