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
+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
+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
+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.
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
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
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.
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
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
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
+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.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