Perhaps this is the obvious answer, but I'm pretty sure a fair number of structures used in the engine are, memory-space wise, portions of larger structures defined elsewhere. This allows the larger structure to be type-cast to a smaller structure for certain operations easily. It is possible that the _zend_executor_globals struct is one of these cases (although I'm not certain without digging through the code), which means the placement of variables within the struct is important.
John On Tue, 2005-07-12 at 00:36 -0400, Jessie Hernandez wrote: > Today I've been debugging a segfault with my namespace patch until I found > that the problem was simply the placement of a variable in a struct. I > still don't see the logic behind it, but I got the segfault both in Windows > 2000 and Linux (FC3). The steps to reproduce this segfault are very simple > (using PHP 5.1.0b2): > > 1) In zend_globals.h, modify the struct _zend_executor_globals and add a > simple HashTable pointer after class_table or zend_constants. It should > look like this: > > ... > HashTable *class_table; /* class table */ > HashTable *my_hash; > HashTable *zend_constants; /* constants table */ > > 2) Compile PHP. Now any script you execute will produce a segmentation > fault. > > 3) Move your hash table to the end of the struct, right before the > "reserved" array: > > HashTable *my_hash; > void *reserved[ZEND_MAX_RESERVED_RESOURCES]; > > 4) make clean (or simply delete all the *.o and *.lo files under Zend/) and > compile PHP again. All executed scripts work as usual, and no segfault is > produced. > > > Does anyone know why this happens? > > > Regards, > > Jessie Hernandez > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
