Shared module problems (core dumps) (under apache 1.3)

Yes, it serves me well now. However this is a way to workaround the
problem.
An the problem exists and I want to hear from core experts (the best will be
if
Zeev or Andi) tell their opinion. I am concerned about this problem.

Cheers,
Andrey

----- Original Message -----
From: "Robert Cummings" robert@wocmud.org
To: "Andrey Hristov" andrey@php.net
Cc: internals@lists.php.net
Sent: Friday, August 29, 2003 7:26 PM
Subject: Re: [PHP-DEV] Shared module problems (core dumps) (under apache
1.3)

The extension_loaded() function might serve you better than
class_exists().

http://www.php.net/manual/en/function.extension-loaded.php

Cheers,
Rob.

Hi,
till today I had a big problem with my Apache 1.3 segfaulting when I try
to
instantiate from a class. The class is declared in a C extesion (named
xml_parser.so, class name WebgateXMLParser). Few week after the
implementation it worked well since I just loaded the extension with
dl() :
dl('xml_parser.so').
At some point I decided to include a check whether the module is loaded
(compiled statically) and in this case not to dl() it. Just around the
time
I
implemented (in PHP) this check my Apache/PHP started to core. Sadly
I found the reason just today.
My check is this :
if (!class_exists('WebgateXmlParser')) { // if it's built into the PHP
binary don't load
dl('xml_parser.so');
}// if
What happens? After the request is finished the module is unloaded -
this
can easily be seen just
by doing a var_dump(get_loaded_extensions()); before the "if". However
PHP/Zend still thinks that
there is WebgateXmlParser class. Briefly : Zend DOES NOT unregister
classes
on module unload.
Now you may imagine what happens when the extension is not loaded since
Zend
Engine thinks that
the class exists (but it does not) and the code tries to instantiate an
object of the class - core dump.

IMO IT IS a bug that the class entries are not unregistered when the
module
is unloaded after the request. I have not tried this but the same error
may
apply to functions exported by a C extension and thus leading
to the same effect - crashes that are hard to explain.

Regards,
Andrey

P.S.
Yes, there is a workaround for my case : to check whether the module is
loaded but not checking whether the class exists.

--

--
.---------------------------------------------.
| Worlds of Carnage - http://www.wocmud.org |
:---------------------------------------------:
| Come visit a world of myth and legend where |
| fantastical creatures come to life and the |
| stuff of nightmares grasp for your soul. |
`---------------------------------------------'

The extension_loaded() function might serve you better than
class_exists().

Read his original mail agian, totally, and you'll see this:

Yes, there is a workaround for my case : to check whether the module is
loaded but not checking whether the class exists.

I still think this is a bug though and should be fixed if possible.

Derick

--
"Interpreting what the GPL actually means is a job best left to those
that read the future by examining animal entrails."

Derick Rethans http://derickrethans.nl/
International PHP Magazine http://php-mag.net/

At 19:49 29/08/2003, Andrey Hristov wrote:

Yes, it serves me well now. However this is a way to workaround the
problem.
An the problem exists and I want to hear from core experts (the best will be
if
Zeev or Andi) tell their opinion. I am concerned about this problem.

Internal classes were not all that popular at the time the module interface
was designed. I guess that because roughly at the same time classes
started becoming more popular, we deprecated dl() - we never got to adding
hooks to unregister classes. You should be able to use zend_hash_del() for
now at MSHUTDOWN, but I'll also add an alias zend_unregister_internal_class().

Zeev