Can you indicate how to reproduce this issue

I have this annoying bug too :(

The bug was appered after last update to 2.5.4
I can't figure out how to reproduce it. Only if I send you the full site copy.
This message is shown at the top of an admincenter, on all pages except home.
If somebody tell me how to identify a source of the problem so I can debug it with Eclipse PDT

So I going to restore to 2.5.3

i got this problem as well...

i'm using windows, zend server, php 5.3.3

hope somebody able to solve it

I get this same problem too!

i'm using windows, zend server, php 5.3.9!

At looking on the Net, it could be related to the use of Zend.

@brunoferrari @mickles - do you guys use Zend Server as well ?

See:
https://bugs.php.net/bug.php?id=50688

```infograf768 commented
See:
https://bugs.php.net/bug.php?id=50688

so possibly the patch is:

I turned off warnings with ini_set before calling usort, then turned them on again after.

This is an effective workaround for now, but I'd love to clean that nastiness out of my code.

I'll try it a little bit later...

And yes, I use windows\zend

PHP Built On

 Windows NT MICKLES7 6.1 build 7601 



Database Version

 5.5.12 



Database Collation

 utf8_general_ci 



PHP Version

 5.2.17 



Web Server

 Apache/2.2.16 (Win32) mod_ssl/2.2.16 OpenSSL/0.9.8o 



WebServer to PHP Interface

 cgi-fcgi 



Joomla! Version

 Joomla! 2.5.3 Stable [ Ember ] 15-March-2012 14:00 GMT 



Joomla! Platform Version

 Joomla Platform 11.4.0 Stable [ Brian Kernighan ] 03-Jan-2012 00:00 GMT 

i wonder if the bug is within the php itself, people should 'scream' at the moment, but in fact it happen to most zend server user....

Any update ??

already a month away.. hope somebody have the solution..

2.5.6 still not solved this problem.... wondering if anybody follow this issue or only me that post from month to month

So can everyone answer the following:
What is your error reporting level?
Do you have debug on?
Is it only in admin and not in site?
Also this is a platform issue so it really should be fixed there.

Please try changing line 463 to

    $errorReporting = error_reporting();
    error_reporting(0);
        usort($a, array(__CLASS__, '_sortObjects'));
    error_reporting($errorReporting);

Hello Elin..
What is your error reporting level?E_ALL & ~E_NOTICE
Do you have debug on? yes
Is it only in admin and not in site?
currently on admin, i see two effect on this, slow joomla that display grid (coz it use jArrayHelper::sortObject() ), Especially on Extension Manager > Manage.

Also on module manager, when i add new.. it mostly display (Serialization of 'SimpleXMLElement' is not allowed), but sometimes it works

i trace both problem with my zend server:
on Manage Extension, the problem happen on administrator/components/com_installer/model/extension.php (line 76):
JArrayHelper::sortObjects($result, $this->getState('list.ordering'), $this->getState('list.direction') == 'desc' ? -1 : 1, true, $lang->getLocale());

on Module Manager, the problem happen on administrator/components/com_modules/models/select.php (line 145):
$items = JArrayHelper::sortObjects($items, 'name', 1, true, $lang->getLocale());

i use '@' and also use your method on error_reporting() , the warning dissapear, it fixed module manager, but still it impact Extension Manager > Manage.. coz the temporary solution is only to hide the message instead find the root of the problem.

The problem is not happen on joomla 2.5.3... so it kind a funny how it happen on joomla 2.5.4 and above while the sortObject function is identical.. i think the way the data sent is different...

i show and demo you the problem : http://youtu.be/__IDvhTHWXQ

Note: it also happen on a clean joomla install, so definitely not because any component or plugin i installed

So I think tha we need to do the same thing in each place in the code where usort is used.

A hunch:
Could it be, that an exception is thrown on the way ?

I can reproduce the PHP warning using the code from the PHP bug tracker

<?php
function cmp($a, $b)
{
    if ($a == $b) {
        return 0;
    }

    try {
        throw new Exception();
    } catch (Exception $e) {

    }

    return ($a < $b) ? -1 : 1;
}

$a = array(3, 2, 5, 6, 1);

usort($a, "cmp");

This results in the mentioned warning on my Linux/PHP 5.3.8 box.

This would also explain why it appears in Joomla! that "suddenly" - Exception were introduced - I don't remember when..

@doxadigital what a nice bug report - I wish more people would take the time to record a video of their bugs - Youtube says more than 1k words :P

It really is a great report. I suspect the reason this may have surfaced is that somewhere we switched something to use an exception instead of an error.

maybe we could trace back to 2.5.4 coz that a significant point of what changes that leads to usort() bugs. No problem 2.5.3... i've been living with this bug for more than 4 months.. i'm glad that @elinw and @elkuku join in the discussion... hopefully we can have the solution :D

I think we need to switch this to a platform discussion.

Ian suggested changing this line
https://github.com/joomla/joomla-cms/blob/0fc0e90cc0b6e59945bdadcef61c38c388e67c6c/libraries/joomla/utilities/arrayhelper.php#L480
so that the arrays are not passed by reference. Can people please test that?

Hi elinw.. i just replace the whole arrayhelper.php with the the one you reference and it seem the bug still occur...

But did you change the one line not to have the &?

do you mean change

protected static function _sortObjects(&$a, &$b)
to
protected static function _sortObjects($a, $b)..

if yes, than i did... the warning and slow process still occures

yes ok thanks

I was wondering why the message was on all pages and I guess it is this inthe admin menu module
$result = JArrayHelper::sortObjects($result, 'text', 1, true, $lang->getLocale());

What's happening on views like article manager and category?

Yes.. its because of administrator/module/mod_menu/helper.php (line 123) that called by default_enabled.php, which is
$result = JArrayHelper::sortObjects($result, 'text', 1, true, $lang->getLocale());

i post some trace result here: http://www.doxadigital.com/scrape/helperphp.jpg
as you see.. it tooks 1.3 seconds to loads.. which is almost 68% of the whole process

are you able to compare with joomla 2.5.3, the problem is happen in that version...
Wish i have skill and capability to help you but this is more advanced than i can handle...

Let me know what to do next...
if you wish i can do screen sharing through skype

I noticed in your screenshot that you are using JDump which generates a few extra warnings. Please report such tricky bugs on a plain vanilla install - just in case ;)

Let's peek...
Could you try and edit the following file:
libraries/joomla/string/string.php on line 740 in 2.5.6 the function transcode()
and insert a
return null;
right at the beginning of this function (to "disable" it) ?

This is a piece of code i stumbled upon, that meets the "requirements" to produce this strange bug..

BTW it's a very strange method that converts a PHP notice into an ErrorException - I don't believe that this is very clever..

I think we got still a long way before we implement exceptions the way they were ment by the guys that invented them ;)

@elkuku
adding in transcode function with "return null;" remove the warning, but still the problem exist...
i took testing on Exention Manager > Manage.. (this page execute usort() two times : in menu and in grid)

with return null... is faster.. you can see here: http://doxadigital.com/scrape/beforeafter.jpg
but i think the bug still there

does string.php is the one who commited this 'crime' for over these month ?

@elkuku , if i 'live' with this (cos it at least make my joomla faster), what the risk would likely happen ?

I'm wondering if it is the fact that usort is running twice that is causing the performance issues i.e. something in particular is happening in that scenario.

What is the language situation on your site? Are you running multilingual? Have you added a language pack?

So the execution time for the file string.php dropped from 7 to 5 seconds. Do you get a value which function in this file spends this time ?

Since you are using Zend, you probably do not use Xdebug..
Xdebug has a nice setting to show exceptions even if they are caught: http://xdebug.org/docs/all_settings#show_exception_trace

If any other person experiencing this bug could try this, that would be helpful.

So I think PHP's iconv() is to blame for this situation (at least in parts).
If you "disable" it, you might loose some sorting functionalities on a "non english" site.

Yes, the platform team should definitely get involved in this discussion ;)

joomla/joomla-platform#1426

Would you try applying this? Then at least you probably won't be pushed through transcode. This is still a separate bug though.

@elinw the problem happen on default installation in joomla, so i don't think this is related to multilingual site. I use English (en-GB) for my site. I'm will test the changes you made and report soon. the usort() is running twice because of the menu and the grid (list of extensions)

@elkuku Zend Server has zend debugger, i'm not aware of the exception trace, maybe there's similiar feature.. what do i need to look for ?

@elinw i already add :
....|| stristr($locale, 'utf8')..

in string.php

and for temporaray remove the return null; in transcode() function
and usort() warning still on

Why is it that your language is being transcoded? What is your locale string?

If you would var_dump $locale and $locale0 that would be helpful.

is there any specific point where can i var_dump those variable.. i print on 'module' level and both are return NULL

Do it right after it is set.

Elin

On Thu, Aug 16, 2012 at 6:06 AM, Viktor notifications@github.com wrote:

is there any specific point where can i var_dump those variable.. i print
on 'module' level and both are return NULL

—
Reply to this email directly or view it on GitHub#179 (comment).

joomla/joomla-platform#1459

Would you be able to do a pull of the platform and run the unit tests and see if you get the same failures Aaron has?

@doxadigital can you post the results of running "locale" and "locale -a" in your server's terminal, please?

@elinw I don't think the issues are related. I'm 98% confident that I know the source of this bug is the issue described by @elkuku, however (#179 (comment)). The _sortObjects callback -> JString::str(case)cmp ->JString::transcode which throws and catches an exception leading to the bug described at https://bugs.php.net/bug.php?id=50688.

The following code should be functionally identical to the transcode function in string.php (https://gist.github.com/3382290). @doxadigital, can you try to replace the old code with this code and see if that fixes the warning. After that would you run the profiler for us again - but this time expand the tree all the way so I can see the timings for each of the subcalls. I'm not convinced that fixing the warning fixes the bottleneck; I'm hedging on the problem being in iconv itself.

Hi.. i'm back again, now with 2.5.7 installed..

@aaronschmitz
"can you post the results of running "locale" and "locale -a" in your server's terminal, please?"
I'm bit lost here.. do you mean "intl.default_locale" setting ?

the code from https://gist.github.com/3382290, make the warning dissapear...

i got some additional info from the console log when run profiler:

Notice: /ercomx2_28072012/libraries/joomla/string/string.php line 744 - iconv() [function.iconv]: Wrong charset, conversion from UTF-8' toCP1252//TRANSLIT,IGNORE' is not allowed

is this mean something ?

on On Profiling, total request is 52960.43 ms (almost a minute)... tested on Extention Manager > Manage

Unfortunately, the it seem there's a lot of jArrayHelper, so i can't give you the exact tree execution... (the image took more than 10000 pixels.. and this is not even half of the tree.. i captured the top here:
http://www.doxadigital.com/scrape/arrayhelper.zip

and the bottom here:
http://www.doxadigital.com/scrape/arrayhelper_bottomscreen.jpg

the middle screen was just jArrayHelper::_sortObjects over and over again

Some additional info
http://www.doxadigital.com/scrape/arrayhelper2.jpg

it calls for :
transcode function 3330 times, with total time 0.329 second
strcmp 1665 times with total 51 second (own time 99.36%)
_sortObjects 1665 times with total 51 second (own time:0.11%)

i think the real problem is on strcmp..

what do you think ?

The problem is definitely in strcmp... which surprises me - I expected the problem to be in transcode.
After a small test myself, it looks like the issue is related to the setlocale call which takes a few milliseconds in my tests.

Please try replacing if (!$locale = setlocale(LC_COLLATE, $locale)) with if ($locale != $locale0 && !$locale = setlocale(LC_COLLATE, $locale)) in the strcmp function in string.php and repost the profilings. In theory, this should reduce the absurd number of times that the locale is set.

Hi.. i did the changes, but no significant improvement...everything still the same

:P - try applying the patch at https://gist.github.com/3780191. Perhaps that will do the trick.

Mmm... there's problem with $this..
Fatal error: Using $this when not in object context in xxxxxxxxx\libraries\joomla\string\string.php on line 399

line 399 is the first "$this->" statement, i.e: if (isset($this->localeCache[$locale]))

did i miss something ?

Hehe - I deserve a pat on the back; I uploaded an old, broken version of my code - not the final patch. Please retry. Sorry about that.

No prob mate... i appreciate all your effort to fix this problem....
i apply the patch, a calling to transcode is gone but the call to strcmp is rising to 2410.

i got a lot of warning:
Illegal offset type in isset or empty , on line: if (isset(self::$localeCache[$locale]))
Illegal offset type, on line: $locale = self::$localeCache[$locale]=$locale1;

Strcmp's Total Time is risen from 51 second to 71 second
screenshot: www.doxadigital.com/scrape/stringphp.jpg

Does anybody know if this issue has been observed in 3.0?

it still happened on clean install joomla 2.5.8
i'll check on 3.x and let u know the result

Hi all,

Any update on this?

While we’re transitioning to a new integrated tracker, could you report the issue on our current main tracker at JoomlaCode and cross-reference each with a link to the other? Here’s the process for reporting on the other tracker:
http://docs.joomla.org/Filing_bugs_and_issues

Thanks for reporting this. At this time we are only using github as the place to submit code fixes so I am closing the report here. The actual reporting of issues and testing fixes is still taking place on Joomlacode.

As it has been some time since you opened this issue can you please confirm that it is still valid with the current Master or Joomla 3.2 beta.

If it is still valid please can you open an item on the Joomlacode tracker in the appropriate area.

CMS Bug Reports: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=8103

CMS Feature Requests: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=8549