tsrm_shutdown() and the CLI SAPI View as Markdown

Silencing the shutdown memory manager doesn't help 'my' bug, although it
probably fixes yours :)

You'd need to be on win32 to see the crash that was introduced by forcing
the DL_UNLOAD call for win32.... unless you want to 'fake it' by adding ZTS
to that 'if' list in the module_destructor.

Thanks for looking though, I know it's a pain in the neck to set up PHP-GTK
builds. Although it'd be easier to remove 'free_ts_id()' from tidy, the CG
global table problem doesn't show up there...

----- Original Message -----
From: "Dmitry Stogov" dmitry@zend.com
To: "'Steph Fox'" steph@zend.com
Cc: "'internals'" internals@lists.php.net
Sent: Thursday, June 01, 2006 1:25 PM
Subject: RE: [PHP-DEV] tsrm_shutdown() and the CLI SAPI

Patch was cutted.

Dmitry.

-----Original Message-----
From: Dmitry Stogov [mailto:dmitry@zend.com]
Sent: Thursday, June 01, 2006 3:05 PM
To: 'Andi Gutmans'; 'Steph Fox'; 'Frank M. Kromann'
Cc: 'internals'; 'Antony Dovgal'; 'Xuefer'
Subject: RE: [PHP-DEV] tsrm_shutdown() and the CLI SAPI

Hi Stepth,

I reproduced crash of php-gtk on linix with php-zts.
I mean running "php -v" then php.ini contains
"extension=gtk2.so". The crash occurs only then php compiled
with --enable-debug.

The reason of the crash is a bug in ZE that is activated by
memory leaks in php-gtk. In case of "php -v" we don't do
request startup/shutdown and as result we don't handle memory
leaks on request shutdown. During tsrm_shutdown()
shutdow_nmemory_manager() is called after sapi_shutdown() and
as result we cannot access sapi_globals then trying to print
information about memory leaks and crashes.

The solution - don't print information about memory leaks
during tsrm_shutdown().

Patch for PHP_5_2 is attached, but it can be manually applied
to any version.

Steph, does you crash(es) go away with this patch?

I am going to commit patch in 24h.
Any objections?

Thanks. Dmitry.

-----Original Message-----
From: Andi Gutmans [mailto:andi@zend.com]
Sent: Thursday, June 01, 2006 10:29 AM
To: Steph Fox; Frank M. Kromann
Cc: 'internals'; 'Antony Dovgal'; Dmitry Stogov; 'Xuefer'
Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI

As we are not planning to release a new version within the next
couple of weeks, I suggest before jumping to conclusions we
take a look at it.

If you really need to comment out that line in the meanwhile
that's OK with me.

Andi

At 09:50 PM 5/31/2006, Steph Fox wrote:

Yes, it would, given the root cause - but would you
really want to
break the whole of PHP for an academic exercise?

It's not really an academic exercise. If we know there's a bug
someplace we should at least look into it and try and
understand it.

Frank's referring to Zeev's three-years-ago decision to simply opt
out of tsrm_shutdown() here... he's suggesting we revert it.

Then if we decide to remove the trsm_shutdown call for a
good reason
(circular dependency, blah blah blah) then we can do that
and put a
nice fat comment on why it's the right thing to do. But I
do think
it's benefical to try and understand what's happening.

Fine, but breaking working code while you're trying to understand
what's happening is far from beneficial to our users. Can't
we at least #0 it?

Andi

--

__________ NOD32 1.1380 (20060125) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com

--

__________ NOD32 1.1380 (20060125) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com

Hi Dmitry,

Have some diagnostics:

1. zend_shutdown() is called before anything in TSRM. It invokes
   zend_hash_graceful_reverse_destroy(&module_registry);

2. module_destructor() is invoked via the hash-destroyer (being part of the
   module_registry hash constructor). This performs the MSHUTDOWN routine for
   each registered module, which in several cases (now) includes a PHP-side
   call to ts_free_id(). The ts_free_id() call usually allows the next stage to
   be unproblematic; it also marks the module's entry in the resource table as
   'done', so that the final clearing loop won't try to double-free it.
   However, ts_free_id() doesn't check for 'done' itself before it frees
   resources.

3. DL_UNLOAD (an alias for FreeLibrary, under doze) is then called on any
   module loaded via dl() or php.ini (checking for a module handle)... it looks
   like this stage might only have happened under Macs on CLI until
   mid-March...

4. tsrm_shutdown() - the final clearing loop - is called via the end of the
   various SAPI source files (in this case, php_cli.c), and any resource that
   hasn't been freed explicitly by this point is freed there.

It won't help our particular situation, but I think automatically calling
ts_free_id() on dl-loaded modules would be better than either blanket
avoidance of tsrm_shutdown() or requiring each module to call ts_free_id()
explicitly during MINIT. Patch(es) to do that in PHP_5_2 branch attached.

The problem in PHP-GTK is we're crashing when the compiler_globals dtor is
called in tsrm_shutdown(), rather than when the gtk_globals dtor is called.
I think this is a ZE problem rather than ours, but see what you think:
somehow, in compiler_globals_dtor(),

compiler_globals->class_table != GLOBAL_CLASS_TABLE

and the compiler_globals->class_table is destroyed and freed because of
that.

• Steph

----- Original Message -----
From: "Dmitry Stogov" dmitry@zend.com
To: "'Steph Fox'" steph@zend.com
Cc: "'internals'" internals@lists.php.net
Sent: Thursday, June 01, 2006 1:25 PM
Subject: RE: [PHP-DEV] tsrm_shutdown() and the CLI SAPI

Patch was cutted.

Dmitry.

-----Original Message-----
From: Dmitry Stogov [mailto:dmitry@zend.com]
Sent: Thursday, June 01, 2006 3:05 PM
To: 'Andi Gutmans'; 'Steph Fox'; 'Frank M. Kromann'
Cc: 'internals'; 'Antony Dovgal'; 'Xuefer'
Subject: RE: [PHP-DEV] tsrm_shutdown() and the CLI SAPI

Hi Stepth,

I reproduced crash of php-gtk on linix with php-zts.
I mean running "php -v" then php.ini contains
"extension=gtk2.so". The crash occurs only then php compiled
with --enable-debug.

The reason of the crash is a bug in ZE that is activated by
memory leaks in php-gtk. In case of "php -v" we don't do
request startup/shutdown and as result we don't handle memory
leaks on request shutdown. During tsrm_shutdown()
shutdow_nmemory_manager() is called after sapi_shutdown() and
as result we cannot access sapi_globals then trying to print
information about memory leaks and crashes.

The solution - don't print information about memory leaks
during tsrm_shutdown().

Patch for PHP_5_2 is attached, but it can be manually applied
to any version.

Steph, does you crash(es) go away with this patch?

I am going to commit patch in 24h.
Any objections?

Thanks. Dmitry.

-----Original Message-----
From: Andi Gutmans [mailto:andi@zend.com]
Sent: Thursday, June 01, 2006 10:29 AM
To: Steph Fox; Frank M. Kromann
Cc: 'internals'; 'Antony Dovgal'; Dmitry Stogov; 'Xuefer'
Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI

As we are not planning to release a new version within the next
couple of weeks, I suggest before jumping to conclusions we
take a look at it.

If you really need to comment out that line in the meanwhile
that's OK with me.

Andi

At 09:50 PM 5/31/2006, Steph Fox wrote:

Yes, it would, given the root cause - but would you
really want to
break the whole of PHP for an academic exercise?

It's not really an academic exercise. If we know there's a bug
someplace we should at least look into it and try and
understand it.

Frank's referring to Zeev's three-years-ago decision to simply opt
out of tsrm_shutdown() here... he's suggesting we revert it.

Then if we decide to remove the trsm_shutdown call for a
good reason
(circular dependency, blah blah blah) then we can do that
and put a
nice fat comment on why it's the right thing to do. But I
do think
it's benefical to try and understand what's happening.

Fine, but breaking working code while you're trying to understand
what's happening is far from beneficial to our users. Can't
we at least #0 it?

Andi

--

__________ NOD32 1.1380 (20060125) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com

--

__________ NOD32 1.1380 (20060125) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com