Re: Weird behaviour with declared PHP classes and GDK drawing functions
| From: | Steph Fox | 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
>