I'll go and roll B3 this evening with or without this fix.
I don't see this as a show stopper and there are other crash bugs anyway.
Does anyone know if Edin is around? I need him to create the Win32 package.
Is there anyone else who has the same system as his set up?
Andi
At 11:05 AM 12/20/2003 +0100, Sebastian Bergmann wrote:
_emalloc(unsigned int 7, char * 0x105fe2cc `string', unsigned int 1255,
char * 0x00000000, unsigned int 0) line 143 + 28 bytes
zend_register_functions(_zend_class_entry * 0x00c33c80,
_zend_function_entry * 0x1079efb0 _tidy_funcs_doc, _hashtable *
0x00c33c9c, int 1, void * * * 0x00b42990) line 1255 + 35 bytes
do_register_internal_class(_zend_class_entry * 0x0012f93c, unsigned int 0,
void * * * 0x00b42990) line 1440 + 32 bytes
zend_register_internal_class(_zend_class_entry * 0x0012f93c, void * * *
0x00b42990) line 1499 + 15 bytes
zend_register_internal_class_ex(_zend_class_entry * 0x0012f93c,
_zend_class_entry * 0x00000000, char * 0x00000000, void * * * 0x00b42990)
line 1467 + 13 bytes
zm_startup_tidy(int 1, int 17, void * * * 0x00b42990) line 694 + 150 bytes
zend_startup_module(_zend_module_entry * 0x1079f2a8 _tidy_module_entry)
line 1179 + 21 bytes
php_startup_extensions(_zend_module_entry * * 0x10764768, int 22) line
1294 + 11 bytes
php_startup_internal_extensions() line 86 + 12 bytes
php_module_startup(_sapi_module_struct * 0x00424418 cgi_sapi_module,
_zend_module_entry * 0x00000000, unsigned int 0) line 1460 + 5 bytes
main(int 1, char * * 0x00b42580) line 1050 + 17 bytes
mainCRTStartup() line 338 + 17 bytes--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
Does anyone know if Edin is around? I need him to create the Win32 package.
Is there anyone else who has the same system as his set up?
Edin makes the win32 package as he has all the libs etc. But it is
weekend so IMO a bad time to roll a release. Why not wait until monday?
I assume not many people checked your rc2 either yet.
I now also now why you really need to switch back the version number as
soon as you have tagged:
(From a fresh CVS checkout):
derick@kossu:/dat/dev/php/php-5.0dev$ ./buildconf
You should not run buildconf in a release package.
use buildconf --force to override this check.
This is because we check if a version is "-dev", otherwise it's a
release and users generally should not use ./buildconf in a release
version. The same thing also broke generation of configure in the
snapshots.
regards,
Derick
At 03:55 PM 12/20/2003 +0100, Derick Rethans wrote:
Does anyone know if Edin is around? I need him to create the Win32 package.
Is there anyone else who has the same system as his set up?Edin makes the win32 package as he has all the libs etc. But it is
weekend so IMO a bad time to roll a release. Why not wait until monday?
I assume not many people checked your rc2 either yet.
Actually I prefer releasing it on the weekend because less ppl will be hurt
if something goes wrong. Anyway, I'll put it up probably tomorrow in any
case. We have often waited for the Win32 builds for a day or two.
I now also now why you really need to switch back the version number as
soon as you have tagged:(From a fresh CVS checkout):
derick@kossu:/dat/dev/php/php-5.0dev$ ./buildconf
You should not run buildconf in a release package.
use buildconf --force to override this check.This is because we check if a version is "-dev", otherwise it's a
release and users generally should not use ./buildconf in a release
version. The same thing also broke generation of configure in the
snapshots.
That's not a good enough reason. It doesn't make sense to put such a
restriction at a time when you're managing a release. In any case, maybe
it's best to fix the snaps script to use --force :)
Andi
Actually I prefer releasing it on the weekend because less ppl will be hurt
if something goes wrong. Anyway, I'll put it up probably tomorrow in any
case. We have often waited for the Win32 builds for a day or two.
What can go wrong with a beta? ;-)
That's not a good enough reason. It doesn't make sense to put such a
restriction at a time when you're managing a release. In any case, maybe
it's best to fix the snaps script to use --force :)
I fixed the snaps to do this... but I really don't understand why it is
a problem to reset the version nr to -dev after tagging. We usually do
this to prevent confusing people using a snapshot because they might
think that they are using a release version (which the version
string tells them).
Derick