Interesting.
http://icu.sourceforge.net/apiref/icu4c/
uclean_8h.html#93f27d0ddc7c196a1da864763f2d8920
Perhaps we should not call u_cleanup() at all..
-Andrei
On Oct 4, 2006, at 1:42 PM, Rob Richards wrote:
That does prevent the crash.
I did find that within zend_shutdown, if I comment out
That does prevent the crash.
I did find that within zend_shutdown, if I comment out the call to
u_cleanup(), then ucol_close doesn't crash within unicode_globals_dtor
during tsrm_shutdown.
If that helps any.
Rob
Andrei Zmievski wrote:
I suppose we can omit the ucol_close() call since we're s
I suppose we can omit the ucol_close() call since we're shutting down
completely and ICU will close all resources anyway on exit, I believe.
-Andrei
On Oct 4, 2006, at 6:28 AM, Rob Richards wrote:
Seems to be a windows only problem for me. Works fine under linux, but
I've tried 3 different
Seems to be a windows only problem for me. Works fine under linux, but
I've tried 3 different builds of the ICU library - even built one from
source - and it always crashes at the same point within the ucol_close call.
Rob
Andrei Zmievski wrote:
Strange. I don't see it here on FreeBSD. Does an
Strange. I don't see it here on FreeBSD. Does anyone else have this
problem?
-A
On Oct 3, 2006, at 4:56 AM, Rob Richards wrote:
I get consistent crashes on windows during shutdown with this change.
Access violation in the dtor at:
ucol_close(unicode_globals->root_collator);
It did open cor
I agree with all of this. Anyone want to update README.UNICODE to
reflect this change?
-Andrei
On Aug 16, 2005, at 4:52 PM, Andi Gutmans wrote:
I think we should make the following assumptions:
a) Being able to create and manipulate IS_UNICODE zvals when
unicode_semantics=off will be very
I think we should make the following assumptions:
a) Being able to create and manipulate IS_UNICODE zvals when
unicode_semantics=off will be very useful to people including the exposing
of the ICU extension.
b) Defining Unicode identifiers like classes/properties/functions if
unicode_semantics=
It does make the engine more complicated though, because we can't just
check for UG(unicode) and expect all identifiers to be of the same
type. We would actually need to amend a lot of API functions to include
passing the identifier type along, e.g. zend_get_active_function()
would need to retu
IIRC if unicode_semnantics=on, we agreed to use Unicode for array offsets
and properties (and do auto-conversion). however, if unicode = off, we
should not do auto conversion but allow php users to manually create
unicode data. when it comes to arrays we agreed that in this case they can
use st
Hello Andrei,
if unicode is enabled we could handle all property/class and function
names as unicode internally and as native strings if unicode is disabled.
However that would be a slowdown, so i asked which is better, ease of coding
or speed. Anyway i'd like to have property keys always be sto
I couldn't parse this. Could you restate your question?
-Andrei
On Aug 16, 2005, at 11:40 AM, Marcus Boerger wrote:
Another thing is if we simply shouldn't treat all class/prop/fun
names as
native strings if unicode is off and as unicode strings if it is on.
Or do
you guys think that woul
Hello Andrei,
i am actually convinced that property and class names should always be of
same string type at least for the property key. If not then how the heck can
we ensure that the code will work? That's why i was asking for %R being used
twice and referencing the same type, that of the hash.
Hmm, should we allow this? It is much easier to deal with having common
identifier type everywhere.
-Andrei
On Aug 15, 2005, at 11:41 PM, Dmitry Stogov wrote:
You aren't right.
It is posiible to have unicode property in non-unicode mode (class
name is
string and property name is unicode).
I'd like to see this in PHP4 too.
-Rasmus
On Tue, 1 Jun 2004, Andrei Zmievski wrote:
> Should we add this to PHP 4 as well?
>
> On Tue, 01 Jun 2004, Andi Gutmans wrote:
> > andiTue Jun 1 07:45:46 2004 EDT
> >
> > Modified files:
> > /ZendEngine2zend.c
I think it's OK to add.
At 09:26 AM 6/1/2004 -0700, Andrei Zmievski wrote:
Should we add this to PHP 4 as well?
On Tue, 01 Jun 2004, Andi Gutmans wrote:
> andi Tue Jun 1 07:45:46 2004 EDT
>
> Modified files:
> /ZendEngine2 zend.c
> Log:
> - If user error handler returns "fa
Should we add this to PHP 4 as well?
On Tue, 01 Jun 2004, Andi Gutmans wrote:
> andi Tue Jun 1 07:45:46 2004 EDT
>
> Modified files:
> /ZendEngine2 zend.c
> Log:
> - If user error handler returns "false" then we relay to the built in error
> handler
>
At 12:54 AM 12/20/2003 +0900, Moriyoshi Koizumi wrote:
On 2003/12/20, at 0:21, Dmitry Stogov wrote:
Hi Moriyoshi,
Yes I am sure. Andi approved this patch today.
I didn't know about your patch.
May be you know some situations when my patch will not work properly?
As far as I looked over the patc
On 2003/12/20, at 1:36, Dmitry Stogov wrote:
I do GC after error_handler execution, because GC stack has limited
size
and if I will try to link old garbage with garbage from error_handler I
can overflow it.
Okay, so it seems my patch was not sufficient as it's still possible
GC stack will overflo
On 2003/12/20, at 0:21, Dmitry Stogov wrote:
Hi Moriyoshi,
Yes I am sure. Andi approved this patch today.
I didn't know about your patch.
May be you know some situations when my patch will not work properly?
As far as I looked over the patch, your patch appears the right fix for
the problem. I a
Zeev Suraski wrote:
> Was it crashing under a specific script, or always?
Always since the "MEGA-patch: namespaces are R.I.P.".
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
http://www.professionelle-softwareentwicklung-mit-php5.de/
Zeev Suraski wrote:
> When was it crashing, prior to that fix?
zend.c:1.231 segfaulted. In zend.c:1.232 I "fixed" the segfault, or
what fix did you mean?
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
http://www.professionelle-soft
At 23:00 05/06/2003, Sebastian Bergmann wrote:
Zeev Suraski wrote:
> It does look like a voodoo fix. What's crashing exactly?
Zeev,
Stanislav already looked into this and the segfault related to
GLOBAL_CONSTANTS_TABLE not beeing malloc()ed in ZTS mode is now gone.
But with a fairly odd fix.
Zeev Suraski wrote:
> It does look like a voodoo fix. What's crashing exactly?
Zeev,
Stanislav already looked into this and the segfault related to
GLOBAL_CONSTANTS_TABLE not beeing malloc()ed in ZTS mode is now gone.
--
Sebastian Bergmann
http://sebastian-bergmann.de/
On Wed, 4 Jun 2003, Sebastian Bergmann wrote:
> Marcus Börger wrote:
> > So he should be forgiven if he doesn't try all version.
>
> Marcus, Derick, *,
>
> relax. Don't "defend" me, as I feel not "offended". For the first time
> I did not test a non-ZTS build before committing a ZTS fix, s
Marcus Börger wrote:
So he should be forgiven if he doesn't try all version.
Marcus, Derick, *,
relax. Don't "defend" me, as I feel not "offended". For the first time
I did not test a non-ZTS build before committing a ZTS fix, so it was a
mistake on my side.
--
Sebastian Bergmann
http://seba
At 15:43 04.06.2003, Sebastian Bergmann wrote:
Thies C. Arntzen wrote:
> i trust you;-) but - after looking thru zend.c - i think that
> the TLS stuff is getting more and more un-maintainable.
What really looks messed up is
#ifdef ZTS
...
#ifdef ZTS
...
#else
...
#end
Thies C. Arntzen wrote:
> i trust you;-) but - after looking thru zend.c - i think that
> the TLS stuff is getting more and more un-maintainable.
What really looks messed up is
#ifdef ZTS
...
#ifdef ZTS
...
#else
...
#endif
...
#endif
--
Sebastian Bergman
Stanislav Malyshev wrote:
> _explain_ what you are doing instead of submitting patched that don't
> even compile?
It compiles fine here (Debug_TS build on Windows).
Without that patch it compiles as well, but segfaults during startup.
See
http://news.php.net/article.php?group=php.inte
28 matches
Mail list logo
