Re: Weird behaviour with declared PHP classes and GDK drawing functions

From: Date: Sun, 30 Oct 2005 16:23:44 +0000
Subject: Re: Weird behaviour with declared PHP classes and GDK drawing functions
References: 1 2  Groups: php.gtk.dev 
Request: Send a blank email to php-gtk-dev+get-1985@lists.php.net to get a copy of this message
:) ----- Original Message ----- From: "Andrei Zmievski" <andrei@gravitonic.com> To: "Steph Fox" <steph@zend.com> Cc: "PHP-GTK dev" <php-gtk-dev@lists.php.net> Sent: Sunday, October 30, 2005 1:04 AM Subject: Re: [PHP-GTK-DEV] Weird behaviour with declared PHP classes and GDK drawing functions > Oh, Zend Engine, the paragon of confoundry and head-scratching > incentivizer. After several hours of enjoy close and intimate > relationship with gdb, this bug should be fixed in CVS. For the > curious ones in the audience, the problem is described in the fix > comment: > > /* > * This is required to trick Zend into performing the global > class table cleanup in a > * different manner. EG(full_table_cleanup) is 0 normally, and > is set to 1 if any > * module is loaded via dl(), because the module may register > internal classes. When > * we register an internal class at runtime, it is added to the > end of the class list. > * shutdown_executor() has to remove user-declared classes from > the class list. It > * does it by iterating through the list in reverse order and > cleaning up all user > * classes until it encounters an internal class, but since we > have just added an > * internal class at the very end, it stops right away and does > not clean up the user > * ones. We circumvent it by pretending to be a dynamically > loaded module so that the > * hash cleanup does not stop on the first internal class and > proceeds through the > * whole table. > * > * Whether there is a better way to do it is still to be seen. > */ > EG(full_tables_cleanup) = 1; > > > -Andrei > > > On Oct 22, 2005, at 9:22 AM, Steph Fox wrote: > > > Andrei, can you look into this please? It's very, very weird. > > > > Try adding the line > > > > class Scribble {} > > > > to the top of the enclosed working script. > > > > That's all you have to do to break the 3 drawing functions in it > > and cause > > PHP-GTK to crash on exit. You don't even need to instantiate the > > class (or > > make it instatiatable, if that's a word). > > > > Outcomment the drawing functions, and it stops crashing. Bizarre. > > > > PHP bug, GTK bug or PHP-GTK bug? > > > > - Steph > > > > <scribble.php.txt> > > -- > > PHP-GTK Development Mailing List (http://gtk.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > -- > PHP-GTK Development Mailing List (http://gtk.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php >

« previous php.gtk.dev (#1985) next »