Everything

php

Session problem

php.internals

Unnamed Person

23 years ago

Any news about this bug

http://bugs.php.net/bug.php?id=22175

?

Tnx

--
michel 'ziobudda' morelli <michel@ziobudda.net>

epplestun

23 years ago

you can see this:

At 23:51 17/03/2003, Andrei Zmievski wrote:

>Today I tried to run PHP-GTK with ZE2 changes against current CVS and it
>segfaulted. I traced it to the fact that
>PG(http_globals)[TRACK_SERVER_VARS] is no longer available if $_SERVER
>is not present in the PHP code, due to the changes Zeev (I think) made
>in order to improve efficiency. I don't quite agree with the way it
>works right now.

Well, it works well though :)  All you have to do is hint PHP that you're
going to touch it, and it will be available for you immediately.  To do
that, simply call:

zend_is_auto_global("_SERVER", sizeof("_SERVER")-1 TSRMLS_CC);

and you're done.  ext/standard/info.c already makes use of this.

Zeev


----- Original Message -----
From: "michel 'ziobudda' morelli" <michel@ziobudda.net>
To: "php-dev" <internals@lists.php.net>
Sent: Tuesday, March 18, 2003 4:31 PM
Subject: [PHP-DEV] Session problem

Rob Richards

23 years ago

I am trying to do a win 32 build from the latest cvs source. After 842
errors I am trying to go through them to figure out what the problems are
that I am having.

The largest source of errors seems to be a change made in February to the
use of winsock2.
winsock.h is getting pulled in first from /arpa/inet.h from the win32build
tools (via the php.h include).
This is causing many redefinition; different linkage errors.
In order to get rid of the errors and allow the the problem files to be
created I include the winsock2.h file prior to including the php.h file.

Does any know wether this may o may not cause any unexpected problems?

The files I found the problems in were:

main/fopen_wrappers.c
main/mergesort.c
extc/ftp/ftp.c
ext/standard/dns.c
ext/standard/ftp_fopen_wrapper.c
ext/standard/http_fopen_wrapper.c
ext/mysql/php_mysql.c
ext/odbc/php_odbc.c
win32/sendmail.c

Rob

Wez Furlong

23 years ago

You are most likely building from the wrong branch.

for PHP5:
co php5

for PHP 4.3.x
co -r PHP_4_3 php4

checking out HEAD from php4 will not work.

--Wez.

On Sun, 23 Mar 2003, Rob Richards wrote:

Rob Richards

23 years ago

Thanks,

working much better now

Rob

----- Original Message -----
From: "Wez Furlong" <wez@thebrainroom.com>
To: "Rob Richards" <rrichards@digarc.com>
Cc: "php-dev" <internals@lists.php.net>
Sent: Sunday, March 23, 2003 1:10 PM
Subject: Re: [PHP-DEV] Win 32 Build problem

Rob Richards

23 years ago

I am getting some serious memory leaks due to the difference between a
module loaded via the ini file and one loaded via a dl call in a script.

When loaded via the ini file, the memory is fine as the resources are killed
in the correct order via the zend_hash_graceful_reverse_destroy call.

When a module is loaded via dl call, the module is removed via the
modules_destructor which kills off the resources in the order they were
created in a script (at least looking at the stack while debugging this is
what it shows is happening).

Is this behavior by design or is it incorrect as some extensions rely on the
reverse destruction on the resources. I would assume this is incorrect as it
now no longer consistent execution of an extension if one were to load the
extension using dl rather than from the ini file.
Running some of them under Windows, php completely dies due to memory access
violations.

Thanks,

Rob

Rob Richards

23 years ago

When an extension is loaded from a script rather than the ini file, the
resources are being destroyed incorrectly.
When I change zend_list and zend_hash to the following, the resources are
now destroyed in the same order as they are when the extension is loaded
from the ini file and no more memory issues (tested under windows).

It seems zend_clean_module_rsrc_dtors should be changed to something along
the lines of:

zend_list.c
void zend_clean_module_rsrc_dtors(int module_number TSRMLS_DC)
{
zend_hash_apply_reverse_with_argument(&list_destructors, (apply_func_arg_t)
zend_clean_module_rsrc_dtors_cb, (void *) &module_number TSRMLS_CC);
}


zend_hash.c
ZEND_API void zend_hash_apply_reverse_with_argument(HashTable *ht,
apply_func_arg_t apply_func, void *argument TSRMLS_DC)
{
Bucket *p;

IS_CONSISTENT(ht);

HASH_PROTECT_RECURSION(ht);
p = ht->pListTail;
while (p != NULL) {
if (apply_func(p->pData, argument TSRMLS_CC)) {
p = zend_hash_apply_deleter(ht, p);
} else {
p = ht->pListTail;
}
}
HASH_UNPROTECT_RECURSION(ht);
}

does this seem to be correct? Basically the only change is that it traverses
the hash table in reverse. didnt make a diff as not sure wether this is
correct logic or if there is a functions already there which would do the
same aszend_hash_apply_reverse_with_argument.

Thanks,

Rob

Rob Richards

23 years ago

My questions for the other day seem a lot off. After going through modules
much more, I need someone to either confirm or explain a little more on how
resources within a module are destroyed. What I am seeing stepping through
the code is the following:

a module loaded from the ini file destroys its resources in the reverse
order that they are created via the script.

a module loaded from a dl command destroys resources in the order that they
are registered in the PHP_MINIT_FUNCTION via
zend_register_list_destructors_ex.

The memory leaks I seem to be seeing then would be due to the fact that
there are some dependencies on the resource destructions, which would mean
that the destructors would need to be defined in the order they should be
destroyed in (to support loading via dl).

Is correct? If not can someone shed a little more light on this?

The problem I am stepping through is in the domxml. php_free_xml_doc is the
first destructor registered, so when the extension is loaded via the dl
command, php_free_xml_doc is the first destructor called, leaving the other
resources (node references, etc..) which were created in the script to crash
when they get called to be destroyed since xmlFreeDoc was already called.

Any info on how the destructors work in the 2 different scenarios would be
greatly helpful.

Thanks,

Rob

Thies C. Arntzen

23 years ago

On Sun, Mar 30, 2003 at 04:34:36PM -0500, Rob Richards wrote:

> My questions for the other day seem a lot off. After going through modules
> much more, I need someone to either confirm or explain a little more on how
> resources within a module are destroyed. What I am seeing stepping through
> the code is the following:
>
> a module loaded from the ini file destroys its resources in the reverse
> order that they are created via the script.
>
> a module loaded from a dl command destroys resources in the order that they
> are registered in the PHP_MINIT_FUNCTION via
> zend_register_list_destructors_ex.
>
> The memory leaks I seem to be seeing then would be due to the fact that
> there are some dependencies on the resource destructions, which would mean
> that the destructors would need to be defined in the order they should be
> destroyed in (to support loading via dl).
>
> Is correct? If not can someone shed a little more light on this?

using dl() is generally not as "good" as loading extensions via
php.ini.

>
> The problem I am stepping through is in the domxml. php_free_xml_doc is the
> first destructor registered, so when the extension is loaded via the dl
> command, php_free_xml_doc is the first destructor called, leaving the other
> resources (node references, etc..) which were created in the script to crash
> when they get called to be destroyed since xmlFreeDoc was already called.

i was the guy that requested the destructors to be called in
reverse order of creation, but i have never invstigated what
happens if extensions are loaded via dl().

>
> Any info on how the destructors work in the 2 different scenarios would be
> greatly helpful.

they shouldn't IMHO. if you could prepare a patch that fixes
this i'm sure it'll be discussed here. but as not too many
ppls actually think that dl() is a GoodFunction(tm) don't
expect that anyone will "jump on" you problem just 'cause you
reported it.

so - my advice: a) include domxml in your php-build -or- b)
load the shared lib via php.ini. if you _have_ to use dl()
during your script (which will always be waaay slower than a
or b) you will have to either c) fix the problem yourself and
propose a patch or d) find someone who does that for you.


my 2c,
tc

Rob Richards

23 years ago

I have 2 different patches that fix this specific issue, but am not sure if
they are actually correct - as there may be a lower level issue, or even
which one would be correct. One patch is on the Zend engine which will go
through the destructor list in reverse within zend_clean_module_rsrc_dtors.
The other is directly in domxml by just moving the php_free_xml_doc call to
the end of the registered destructor list.

Which is actually correct, I have no idea. There is no documentation on
which order destructors should be defined within a module, so dont know if
there is a standard already in place. As you note it is most likely due to
dl() not being a good function and few modules probably have a dependency
issue like this. Although it is not an ideal way to load extensions, the
function does exist.

The real issue comes down to why when coming from the ini file, things are
destroyed in reverse from how they were created within a php script, while
if loaded from dl(), they are destroyed based on the order the destructors
are defined within the module. Is this really a lower level issue and I am
just seeing the surface of it? This is one sure fire way to dive into the
engine piece I can tell you.

On  31 Mar 2003, Thies C. Arntzen wrote:

>
>     using dl() is generally not as "good" as loading extensions via
>     php.ini.
>
> > The problem I am stepping through is in the domxml. php_free_xml_doc is

the

> > first destructor registered, so when the extension is loaded via the dl
> > command, php_free_xml_doc is the first destructor called, leaving the

other

> > resources (node references, etc..) which were created in the script to

crash

> > when they get called to be destroyed since xmlFreeDoc was already

called.

>
>     i was the guy that requested the destructors to be called in
>     reverse order of creation, but i have never invstigated what
>     happens if extensions are loaded via dl().
>
> > Any info on how the destructors work in the 2 different scenarios would

be

Rob Richards

23 years ago

This patch fixes Bug #22774 PHP crashes when exiting.

All it does is move the registration of the php_free_xml_doc destructor to
the end of the list, so it is called after destroying nodes and attributes
in the instances where the domxml extension is loaded via a dl() call.
It seems the only time that the order of destructors matters is in the event
of being loaded by dl().

Thanks,

Rob

Rob Richards

23 years ago

Patch didnt get attached in last message.

It can be found here: http://www.digarc.com/php_domxml.c.diff

Christian Stocker

23 years ago

On Wed, 2003-04-02 at 12:26, Rob Richards wrote:

> Patch didnt get attached in last message.
>
> It can be found here: http://www.digarc.com/php_domxml.c.diff

applied. thanks

chregu

Rob Richards

23 years ago

Here is a patch for domxml which implements the set_attribute_node method.

Located at: http://www.digarc.com/php_domxml.diff

One thing to note is in the section where an attribute already exists. As
there can't be dunplicate attributes, only the content from the new
attribute node is moved to the existing attribute node. Unlinking the
origional attribute node could potential cause a memory leak as it may never
be freed.

Rob

Christian Stocker

23 years ago

On Thu, 2003-04-03 at 11:31, Rob Richards wrote:

> Here is a patch for domxml which implements the set_attribute_node method.
>
> Located at: http://www.digarc.com/php_domxml.diff
>
> One thing to note is in the section where an attribute already exists. As
> there can't be dunplicate attributes, only the content from the new
> attribute node is moved to the existing attribute node. Unlinking the
> origional attribute node could potential cause a memory leak as it may never
> be freed.

Commited and thanks

chregu