Re: 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