update.php fails with IntlException on 1.36 and 1.37 after upgrade from 1.35
Closed, DeclinedPublicBUG REPORT
Actions

Assigned To

None

Authored By

	Epopen
	Dec 3 2021, 7:46 AM

Description

List of steps to reproduce (step by step, including full links if applicable):

$ php ./update.php in directory of maintenance.

What happens?:
update.php run broken and got error as below.

IntlException from line 3252 of /home/www/mediawiki/includes/language/Language.php: Constructor failed
#0 /home/www/mediawiki/includes/language/Language.php(3252): NumberFormatter->__construct('en', 0, '#,##0.###')
#1 /home/www/mediawiki/includes/language/Language.php(3195): Language->formatNumInternal('0.6', false, false)
#2 /home/www/mediawiki/includes/language/Language.php(4609): Language->formatNum('0.6')
#3 /home/www/mediawiki/maintenance/update.php(217): Language->formatTimePeriod(0.61092710494995)
#4 /home/www/mediawiki/maintenance/doMaintenance.php(108): UpdateMediaWiki->execute()
#5 /home/www/mediawiki/maintenance/update.php(264): require_once('/home/www/www.e...')
#6 {main}

The error message generated by version 1.37
Mediawiki malfunction caused.

What should have happened instead?:
Upgrade successful, Mediawiki work fine.

Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc:

Host: FreeBSD 13.0-RELEASE
Mediawiki (upgrade from): 1.35
Mediawiki (upgrade to): 1.36 and 1.37
PHP: 7.4.26
PHP-intl: 7.4.26
MySQL: 8.0.27

Related Objects

Mentioned Here: rMWce8d0e9599a8: Update formatNum implementation to match tr35 and latest CLDR

Event Timeline

Epopen created this task.Dec 3 2021, 7:46 AM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 3 2021, 7:46 AM

Epopen added projects: MW-1.37-release, MW-1.36-release, MW-1.35-release.Dec 3 2021, 8:21 AM

Reedy renamed this task from Upgrade from 1.35 to 1.36 & 1.37 by CLI to update.php fails with IntlException on 1.36 and 1.37 after upgrade from 1.35.Dec 3 2021, 3:02 PM

Reedy added a project: MediaWiki-Internationalization.

new NumberFormatter('en', 0, '#,##0.###'); doesn't fail for me on PHP 8 on macOS (obviously this isn't conclusive of anything, other than the syntax is valid in at least some versions)

It could be an issue with your system locales, the PHP build or freebsd more generally.

That being said digitGroupingPattern isn't defined in MW-1.35-release, it was added in rMWce8d0e9599a8: Update formatNum implementation to match tr35 and latest CLDR; so it is "new" code in 1.36/1.37 in that regard.

CC @santhosh and @cscott as authors of the patch

Hi @Reedy and @santhosh

About system locales and PHP build as below.

System locales (Output as command "locales")

LC_CTYPE="C"
LC_COLLATE="C"
LC_TIME="C"
LC_NUMERIC="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=zh_TW.UTF-8

PHP Build (Build C argument)

--- ext/date/lib/parse_iso_intervals.lo ---
/bin/sh /usr/PortsWRKDIR/usr/ports/lang/php74/work/php-7.4.26/libtool --silent --preserve-dup-deps --mode=compile cc -Iext/date/lib -DZEND_ENABLE_STATIC_TSRMLS_CACHE=1 -DHAVE_TIMELIB_CONFIG_H=1 -Iext/dat
e/ -I/usr/PortsWRKDIR/usr/ports/lang/php74/work/php-7.4.26/ext/date/ -DPHP_ATOM_INC -I/usr/PortsWRKDIR/usr/ports/lang/php74/work/php-7.4.26/include -I/usr/PortsWRKDIR/usr/ports/lang/php74/work/php-7.4.26
/main -I/usr/PortsWRKDIR/usr/ports/lang/php74/work/php-7.4.26 -I/usr/PortsWRKDIR/usr/ports/lang/php74/work/php-7.4.26/ext/date/lib -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/PortsWRKDIR/usr
/ports/lang/php74/work/php-7.4.26/TSRM -I/usr/PortsWRKDIR/usr/ports/lang/php74/work/php-7.4.26/Zend  -I/usr/local/include -D_REENTRANT -D_THREAD_SAFE  -O2 -pipe -march=native -fstack-protector-strong -fn
o-strict-aliasing -fvisibility=hidden -Wall -Wno-strict-aliasing -DZTS -DZEND_SIGNALS   -c /usr/PortsWRKDIR/usr/ports/lang/php74/work/php-7.4.26/ext/date/lib/parse_iso_intervals.c -o ext/date/lib/parse_i
so_intervals.lo

Please tell me any request.

Thanks a lot.

Hi ALL

May data corruption in database?
Have hint for debug?

Thanks a lot.

Epopen added a comment.Feb 1 2022, 12:20 PM

This comment was removed by Epopen.

Hi All

The issue no way to fix look like.
Try upgrade @ 1.36 if it support PHP 8.x

Thanks a lot.

Epopen closed this task as Declined.Mar 22 2022, 6:25 AM

Epopen unsubscribed.Apr 7 2022, 3:09 PM

I just ran into this today upgrading 1.42 to 1.43

Also on FreeBSD, PHP 8.

Purging caches...done.
IntlException from line 4484 of /w/includes/language/Language.php: Constructor failed
#0 /w/includes/language/Language.php(4484): NumberFormatter->__construct('en', 0, '#,##0.###')
#1 /w/includes/language/Language.php(4459): MediaWiki\Language\Language->createNumberFormatter('en', '#,##0.###')
#2 /w/includes/language/Language.php(3187): MediaWiki\Language\Language->getNumberFormatter()
#3 /w/includes/language/Language.php(3139): MediaWiki\Language\Language->formatNumInternal('0.2', false, false)
#4 /w/includes/language/Language.php(4289): MediaWiki\Language\Language->formatNum('0.2')
#5 /w/maintenance/update.php(219): MediaWiki\Language\Language->formatTimePeriod(0.21421909332275)
#6 /w/maintenance/includes/MaintenanceRunner.php(703): UpdateMediaWiki->execute()
#7 /w/maintenance/run.php(51): MediaWiki\Maintenance\MaintenanceRunner->run()

I'm not a PHP person, but if I put this in a test file and run it in the same way, it works. Not sure what it is about the update script that causes it to fail.

<?php

$formatter  = new NumberFormatter('en', 0, '#,##0.###');
echo var_dump($formatter);

?>

update.php fails with IntlException on 1.36 and 1.37 after upgrade from 1.35Closed, DeclinedPublicBUG REPORTActions

Description

Related Objects

Event Timeline

update.php fails with IntlException on 1.36 and 1.37 after upgrade from 1.35
Closed, DeclinedPublicBUG REPORT
Actions