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

From: Date: Fri, 29 Aug 2003 16:49:06 +0000
Subject: Re: Shared module problems (core dumps) (under apache 1.3)
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-4247@lists.php.net to get a copy of this message
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. > > > On Fri, 2003-08-29 at 09:17, Andrey Hristov wrote: > > 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. > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > -- > .---------------------------------------------. > | 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. | > `---------------------------------------------' > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >

« previous php.internals (#4247) next »