Short version:
zend_config.w32.h
#define USE_ZEND_ALLOC 1
-#define HAVE_ALLOCA 1
-#define HAVE_LIMITS_H 1
+
+#include <../main/config.w32.h>
In theory that's OK because main/config.w32.h has '#define HAVE_ALLOCA 1'
halfway down it.
In practice, the order actually matters.
- Steph
----- Original Message -----
From: "Dmitry Stogov" <[EMAIL PROTECTED]>
To: "'Steph Fox'" <[EMAIL PROTECTED]>
Cc: "'PHP-GTK dev'" <[EMAIL PROTECTED]>; "'internals'"
<internals@lists.php.net>
Sent: Tuesday, May 30, 2006 5:36 AM
Subject: RE: [PHP-DEV] Ides of March [WAS: tsrm_shutdown() and the CLI SAPI]
Hi Steph,
As I remember this patch modified "zend_config.w32.h". It made inclusion
of
"main/config.w32.h" in the same way as on all other systems.
How it affects TSRM?
May be I forgot something.
Thanks. Dmitry.
-----Original Message-----
From: Steph Fox [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 30, 2006 1:30 AM
To: Dmitry Stogov
Cc: 'PHP-GTK dev'; 'internals'
Subject: Re: [PHP-DEV] Ides of March [WAS: tsrm_shutdown()
and the CLI SAPI]
Hi Dmitry,
Finally cracked it, and you're right it had nothing to do
with the suspected
optimizations. There was a win32 memory fix where you
included the PHP win32
config file in the Zend one, confusing heck out of TSRM's totally
independent (until it meets Zend) alloca definition, which is
some way
before Zend meets PHP's. They all need to match.
Can you find some other way to fix #36568 pliz?
I'll take another look at those flags in TSRM itself for the
work-aroundable
shutdown issues when I've caught up with the weeklies...
- Steph
ps I knew it had to be you - nobody else did anything major
in core that
week ;)
> Hi Steph,
>
> I have no idea what is wrong with optimized class/functions tables
> cleanup.
> In case if EG(full_tables_cleanup) is set, the behavior
should be exactly
> the same as before patch.
> PHP uses EG(full_table_cleanup) only for dl(), but I do't
know how php-gtk
> uses it.
>
> Thanks. Dmitry.
>
>> -----Original Message-----
>> From: Steph Fox [mailto:[EMAIL PROTECTED]
>> Sent: Monday, May 29, 2006 1:40 PM
>> To: internals
>> Cc: PHP-GTK dev; Dmitry Stogov
>> Subject: [PHP-DEV] Ides of March [WAS: tsrm_shutdown() and the CLI
>> SAPI]
>>
>>
>> Hi all,
>>
>> I've spent a fun weekend debugging TSRM and bits of ZE2, having
>> finally figured that the zend_compiler_globals dtor was
the point of
>> failure here.
>>
>> TSRM needs to mark resources as 'done' following a free
and doesn't
>> in most cases, but that's actually not the main problem we have in
>> PHP-GTK (although
>> fixing it may well solve everybody else's, I'll check that on
>> my travels).
>>
>> Dmitry's "Optimized cleanup loops on request shutdown"
>> commit(s) spanning
>> the 13th and 14th March broke Andrei's
>> 'EG(full_tables_cleanup) = 1' ruse
>> (we needed user classes to be cleaned and internal classes
to stay),
>> but it also broke TSRM shutdown completely for us. PHP-GTK classes
>> are recognized
>> as being internal, but only the first one ever reaches the
>> dtor - even when
>> there are no user-defined classes.
>>
>> zend_hash_reverse_apply() is called at that point, so I'm guessing
>> there's a reentrancy issue behind my access violation crash.
>>
>> I'll get back to this when I get some time, in the
meantime if anyone
>> (Dmitry?) wants to play with this you need to know that I
can't put
>> the 5_2 compat stuff into CVS until Andrei OKs it, so PHP-GTK HEAD
>> has to be built
>> against PHP_5_1 branch at present (anything after March
14th will do).
>>
>> - Steph
>>
>>
>> > Under CLI ZTS build, when loading a PHP-GTK 2 .dll built against
>> > anything this side of PHP 5.1.2 release, I'm seeing an 'access
>> violation' crash on
>> > reaching:
>> >
>> > if (resource_types_table && !resource_types_table[j].done &&
>> > resource_types_table[j].dtor) {
>> > resource_types_table[j].dtor(p->storage[j],
&p->storage);
>> > }
>> >
>> > Similar code is also used in:
>> >
>> > tsrm_free_interpreter_context()
>> > ts_free_thread()
>> > ts_free_worker_threads()
>> > ts_free_id()
>> >
>> > I thought ts_free_thread() was crashing at that line too at
>> first, but
>> > that turned out to be because there's no 'done' check
>> there, i.e. double
>> > dtors are possible via some functions. It's still vaguely
>> possible there's
>> > a double flypast causing the crash I'm seeing, but I have
>> everything I
>> > know about protected now. (On my laptop that is.)
>> >
>> > Eventually I found the resource id for PHP-GTK - the
only extension
>> > I'm loading during runtime, via php.ini - is 32nd out of
a possible
>> > 32. "Eventually", because that means I can't use ts_free_id()
>> to avoid the
>> > crash as advised by Frank (and Tony, and Dmitry, and anyone
>> else who ever
>> > used that MSHUTDOWN workaround for CLI). Interesting too,
>> because the
>> > resource that causes the crash appears to be something
>> completely other.
>> > Tracking down resource id #5 - and that's all I know about
>> it apart from
>> > it crashes - is a barrel of laughs, I'll let y'all know if
>> I ever find out
>> > which of the many possible extensions/files in ext/standard
>> or core it is.
>> >
>> > Short version: One line is problematic, and only in one
>> function, and
>> > presumably only under CLI SAPI. (CGI already doesn't call
>> tsrm_shutdown(),
>> > thanks to similar issues some 3 years ago).
>> >
>> > The question is whether to take 'the Zeev approach' and
>> simply comment
>> > out
>> > the tsrm_shutdown() call at the end of sapi/cli/php_cli.c,
>> or whether to
>> > spend time knitting up a fine-grained approach to prevent
>> the one bad line
>> > in the function from being called in single-threaded
>> environments? I think
>> > I've given up on the idea of actually resolving the bug now...
>> >
>> > Thoughts?
>> >
>> > - oh, and don't make one of them 'chicken-and-egg' - this is
>> > definitively NOT related to the shutdown order in main.c!!!!!
>> >
>> > - Steph
>> >
>> > --
>> > PHP Internals - PHP Runtime Development Mailing List
>> > To unsubscribe, visit: http://www.php.net/unsub.php
>> >
>> >
>> > __________ NOD32 1.1380 (20060125) Information __________
>> >
>> > This message was checked by NOD32 antivirus system.
>> > http://www.eset.com
>> >
>> >
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
> __________ NOD32 1.1380 (20060125) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
__________ NOD32 1.1380 (20060125) Information __________
This message was checked by NOD32 antivirus system.
http://www.eset.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
