And what does it say in your error logs?

On 6 September 2016 at 19:09, sshcli notifications@github.com wrote:

Steps to reproduce the issue

1. Create more than 125,000 user accounts or test in a website with a similar amount of existing users.
2. Backend->Users->Manage->Show All users

Expected result

You should see all users without any error
Actual result

You will get a HTTP Error 500 Internal Server Error
System information (as much as possible)

Joomla 3.6.2
PHP 7.0.10
MySQL 5.6.31
Apache 2.4.23
Additional comments

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#11958, or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8aWU3Yq4HGOaNkKQ6SajBhf5YJg7ks5qnaxqgaJpZM4J2Hxe
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Nothing in:
PHP Logs
Apache Logs
Joomla Logs

Any idea of another place I can find logs?

Did you try with error reporting to max?

Chrome error:
The example.com page isn’t working

example.com is currently unable to handle this request.
HTTP ERROR 500

To be honest I wouldnt expect it to work displaying all those records but
without seeing the log cant be certain

On 6 September 2016 at 19:28, zero-24 notifications@github.com wrote:

Did you try with error reporting to max?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#11958 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8dux2KVGEFcFfSCBKimzNU3WrIJ4ks5qnbDggaJpZM4J2Hxe
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Internet explorer:

URL where I get the error:
http://example.com/administrator/index.php?option=com_users&view=users

Ok, with Error Reporting = Maximum I get these lines:

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 4096 bytes) in /home/example/public_html/libraries/joomla/database/driver/mysqli.php on line 886

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /home/example/public_html/libraries/vendor/joomla/registry/src/Registry.php on line 77

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in Unknown on line 0

Contact your hoster and tell him to raise your PHP memory limits. That will fix the issue.

Closing as it is not a core issue by itself.

Which is exactly what @bakual said

On 6 September 2016 at 19:39, sshcli notifications@github.com wrote:

Ok, with error report = Max I get this:

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to
allocate 4096 bytes) in /home/example/public_html/
libraries/joomla/database/driver/mysqli.php on line 886

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to
allocate 20480 bytes) in /home/example/public_html/
libraries/vendor/joomla/registry/src/Registry.php on line 77

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to
allocate 20480 bytes) in Unknown on line 0

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#11958 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8Yw-7aWx8A0MZvZ30faZ8m7wv6Qjks5qnbN1gaJpZM4J2Hxe
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

I have access to raise my PHP memory limits.
But I think there are other solutions that you can take into consideration

These are a few options:

Option 1
Load more button

Option 2
Load more while scrolling down

Option 3
Add bigger numbers in the drop down menu (1k, 2k, 3k)

Option 4
A Joomla message "You can't perform this task because you memory is limited to bla bla bla"

Bakual said: Contact your hoster and tell him to raise your PHP memory limits.

@Bakual Option 4 is a good choice to warn users and avoid the same error being reported here once and again.

Unfortunately if you tihnk about it - its not possible to say there isnt
enough memory until you do it and see there isnt enough memory - which is
what your server error logs are for

On 6 September 2016 at 20:31, sshcli notifications@github.com wrote:

Bakual said: Contact your hoster and tell him to raise your PHP memory
limits.

@Bakual https://github.com/Bakual Option 4 is a good choice to warn
users and avoid the same error being reported here once and again.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#11958 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8db1xz4owCkmzjU0GVXnYK6VFJX6ks5qnb-SgaJpZM4J2Hxe
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Any checks you could conceivably come up with are arbitrary limitations imposed or checked by the application. My local environments where I commonly have memory_limit = 2048M shouldn't get warnings based on an assumed "default" hosting configuration of memory_limit = 256M. Depending on how the code is written, it can work around memory limit issues or get more efficient use out of the memory (i.e. using PHP 5.5's Generators feature an operation that was once failing processing over 225K records now runs smoothly (albeit slow because there's so much data) while handling over 650K records). So without knowing the context of the code the warning would be a false positive.

All that can be done is make recommendations on the PHP configurations. But we can't implement effective warnings beyond that other to say "for general use, we recommend this setting have this value". A high memory operation like loading 125K users into the UI at any stage is going to fail without going through a lot of memory optimized operations, a lot of which you just can't do in a PHP 5.3 or 5.4 environment.

Mates, I understand your point, and I respect that.
I know all of you are super developers with a lot of knowledge, but sometimes you must think as a mere mortal.

Why users must get an error if you have the skills and knowledge to prevent it?

Forget about Joomla project for a second, and take this issue as a challenge to yourself

Best regards,

Only with the skills of a mind reader and the ability to see into the
future would anyone have the skills and knowledge to prevent an error

An out of memory error is not an error that can be caught and handled in PHP. That's why we can't convert it to a "user friendly" error; the PHP process comes to a dead stop as soon as you hit that error with no chance of recovery or error handling (even with custom error handlers in place, this emits an E_ERROR type error internal to the PHP engine and that is not an error type that can be handled with a custom handler, see the set_error_handler() docs for more on that).

Which goes back to what I said above. If you try to implement these types of checks in front of operations, they're going to be arbitrary limitations and are most likely not going to accurately reflect the user's environment.

What about Option 3 ?
There is a huge difference between 500 and 125,000

Whatever we put there someone will hot a memory limit

On 6 September 2016 at 21:22, sshcli notifications@github.com wrote:

What about Option 3 ?
There is a huge difference between 500 and 125,000

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#11958 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8eR2Lx_9maUsnR6RszJOY4vnuh09ks5qnctpgaJpZM4J2Hxe
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Well, there is a secondary problem caused by this.
Not mentioned before.

In google chrome
If you tried to view ALL users in the past and got the 500 error, you will probably get this error again in the future until you clear joomlacache/browsercache/cookies/etc.., because for some reason it will try to open the user management showing ALL users by default.

Yep, it is saved in the user session. That session is killed when you close the browser.
In the case of Chrome, you also need to kill the "desktop notification" and other potential processes it is running. Only then it will flush the session cookie. Basically it's a Chrome bug.