# Current HEAD segfaults when built --with-tidy on Windows

- Thread: https://externals.io/message/6651
- Original archive: https://news-web.php.net/php.internals/6651
- Started by Andi Gutmans on 2003-12-20T14:41:43+00:00
- Messages: 4
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #6651 — Andi Gutmans — 2003-12-20T14:41:43+00:00

URL: https://externals.io/message/6651#6651

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/

---

## #6652 — Derick Rethans — 2003-12-20T14:55:36+00:00

URL: https://externals.io/message/6651#6652 · In reply to: #6651

> 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

---

## #6653 — Andi Gutmans — 2003-12-20T17:46:55+00:00

URL: https://externals.io/message/6651#6653 · In reply to: #6651

At 03:55 PM 12/20/2003 +0100, Derick Rethans wrote:
>
>
> > […]
>
>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

---

## #6655 — Derick Rethans — 2003-12-20T18:51:50+00:00

URL: https://externals.io/message/6651#6655 · In reply to: #6653

> 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