Stats page triggers a HTTP 500

[GoogleCodeExporter]

What steps will reproduce the problem?
1. http://kb.sotek-eve.net/?a=self_detail
2. redirects to http://kb.sotek-eve.net/?a=alliance_detail&all_ext_id=1498727871
3. sometimes triggers a http 500

What is the expected output? What do you see instead?
HTTP 500, underwater logging shows:
default limit (64MB): [06-Dec-2011 12:53:38] PHP Fatal error:  Allowed memory 
size of 67108864 bytes exhausted (tried to allocate 83 bytes) in 
/home/vhosting/d/vhost0036456/domains/sotek-eve.net/htdocs/kb/common/pheal/Pheal
RowSet.php on line 49

upgraded limit (128MB)
[06-Dec-2011 12:56:38] PHP Fatal error:  Allowed memory size of 134217728 bytes 
exhausted (tried to allocate 72 bytes) in 
/home/vhosting/d/vhost0036456/domains/sotek-eve.net/htdocs/kb/common/pheal/Pheal
RowSet.php on line 49

What version of the board are you using? e.g. 3.2.3 or 4.0 revision
4b53033f8a1b.
4.0.0 (Crucible) Build Dev

What version of PHP and MySQL does the board run on?
5.3.2-1

What is the url of a page where the error occurs or has occurred?
See reproduction steps

Please provide any additional information below.
Raised the limit to 128MB problem still not solved as it triggers the 500

Original issue reported on code.google.com by Zero.NRG.NL on 6 Dec 2011 at 12:10

[GoogleCodeExporter]

Forgotten to mention that this did not happen in 3.2 or happened less (or I've 
been unaware)

Original comment by Zero.NRG.NL on 6 Dec 2011 at 1:32

[GoogleCodeExporter]

after update to 4.0.1.

[07-Dec-2011 10:54:09] PHP Fatal error:  Allowed memory size of 134217728 bytes 
exhausted (tried to allocate 64 bytes) in 
/home/vhosting/d/vhost0036456/domains/sotek-eve.net/htdocs/kb/common/pheal/Pheal
RowSet.php on line 52

[07-Dec-2011 11:00:27] PHP Fatal error:  Allowed memory size of 134217728 bytes 
exhausted (tried to allocate 10 bytes) in 
/home/vhosting/d/vhost0036456/domains/sotek-eve.net/htdocs/kb/common/pheal/Pheal
RowSet.php on line 49

Original comment by Zero.NRG.NL on 7 Dec 2011 at 10:03

[GoogleCodeExporter]

as resulting step of this error I moved the environment back to my live "beta"

all url have changed to beta.sotek-eve.net
or ****/beta/common/****

Original comment by Zero.NRG.NL on 8 Dec 2011 at 8:28

[GoogleCodeExporter]

You're not the only one with this error but I have yet to work out a cause. 
Obviously a lot of memory is used up by Pheal building the alliance xml, which 
is large, but on my system this only uses 10MB. On other systems it uses 10x as 
much. Same code, various PHP versions.

If you can, try a more recent release of PHP. If it's a problem in PHP or the 
simplexml library this may help.

Original comment by kovellia on 9 Dec 2011 at 2:18

• Changed state: Accepted
• Added labels: Milestone-Release4.1, Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

The annoying thing is that the current hosting provider is using: 
PHP Version 5.3.2-1, as this is a managed environment I have no control over 
their version management.

In my local XAMPP environment I am running: PHP Version 5.3.8
The same files + database from the hosted environment runs, though I am unable 
to measure the difference between both environments (my coding experience is 
from 5 years back :P)

Do you have some sample information I can use to at least try the simplexml 
solution?
This might contribute in trouble shooting.

Original comment by Zero.NRG.NL on 9 Dec 2011 at 9:59

[GoogleCodeExporter]

Im getting a 500 server error when going to the stats page of EDK 4.0.1.

PHP 5 = 5.2.8-3 

It used to work in with the previous version of the EDK.

Original comment by reddrago...@gmail.com on 10 Dec 2011 at 4:35

[GoogleCodeExporter]

Had a similar issue with the stats page myself that may be the same root cause. 
 I was getting a "server returned no data" error on the front end, and apache 
logs were showing segfaults on the spawned processed for the page request.  

I did a core dump, and traced the issue to Zend Garbage Collection. Since Zend 
may be installed on some systems and not others, this could explain the Why is 
happens on some systems and not others.

adding 

php_flag zend.enable_gc off 

 to my .htaccess file solved my problem.  Regrettably, I don't know enough about the edk codebase nor zend internals to actually find the root cause of the issue in the edk code, but perhaps this will give you guys a place to start.

Original comment by mike.fos...@gmail.com on 12 Dec 2011 at 2:30

[GoogleCodeExporter]

@Mike
implemented the .htaccess solution as you suggested, seems to work on my "beta" 
installation.

@Kov
think this might be a proper workaround

Original comment by Zero.NRG.NL on 12 Dec 2011 at 2:45

[GoogleCodeExporter]

Glad it worked, but there has to be something more going on here.  I looked 
into it a little more this morning, and default configurations should enable 
zend_gc by default on most systems, so there must be some other configuration 
option that is causing it on certain systems..

here's relevant phpinfo data on my server
PHP API 20090626
PHP Extension   20090626
Zend Extension  220090626
Zend Extension Build    API220090626,NTS
PHP Extension Build API20090626,NTS
Debug Build no
Thread Safety   disabled
Zend Memory Manager enabled
Zend Multibyte Support  disabled
zend.enable_gc  On  On

and 2 identical codebases sharing the same database, the first has disabled 
zend_gc in htaccess, the other hasn't.

http://kb.f-con.us/?a=alliance_detail&all_ext_id=1006830534
http://kbtest.f-con.us/?a=alliance_detail&all_ext_id=1006830534

and the core dump backtrace on the bad one

Program terminated with signal 11, Segmentation fault.
#0  0xb6f7a859 in gc_remove_zval_from_buffer () from 
/usr/lib/apache2/modules/libphp5.so

#0  0xb6f7a859 in gc_remove_zval_from_buffer () from 
/usr/lib/apache2/modules/libphp5.so
#1  0xb6f4ea38 in _zval_ptr_dtor () from /usr/lib/apache2/modules/libphp5.so
#2  0xb6f684d4 in zend_hash_destroy () from /usr/lib/apache2/modules/libphp5.so
#3  0xb6df1d28 in ?? () from /usr/lib/apache2/modules/libphp5.so
#4  0xb6f82052 in zend_objects_store_free_object_storage () from 
/usr/lib/apache2/modules/libphp5.so
#5  0xb6f4eddd in ?? () from /usr/lib/apache2/modules/libphp5.so
#6  0xb6f5beef in ?? () from /usr/lib/apache2/modules/libphp5.so
#7  0xb6f00788 in php_request_shutdown () from 
/usr/lib/apache2/modules/libphp5.so
#8  0xb6fedb0c in ?? () from /usr/lib/apache2/modules/libphp5.so
#9  0xb76dc181 in ap_run_handler (r=0xb8974da0) at 
/build/buildd/apache2-2.2.14/server/config.c:159
#10 0xb76dff67 in ap_invoke_handler (r=0xb8974da0) at 
/build/buildd/apache2-2.2.14/server/config.c:373
#11 0xb76ef898 in ap_process_request (r=0xb8974da0) at 
/build/buildd/apache2-2.2.14/modules/http/http_request.c:282
#12 0xb76ec3c8 in ap_process_http_connection (c=0xb895fcc0) at 
/build/buildd/apache2-2.2.14/modules/http/http_core.c:190
#13 0xb76e49f1 in ap_run_process_connection (c=0xb895fcc0) at 
/build/buildd/apache2-2.2.14/server/connection.c:43
#14 0xb76f552a in child_main (child_num_arg=<value optimized out>) at 
/build/buildd/apache2-2.2.14/server/mpm/prefork/prefork.c:662
#15 0xb76f58ae in make_child (s=<value optimized out>, slot=0) at 
/build/buildd/apache2-2.2.14/server/mpm/prefork/prefork.c:758
#16 0xb76f5c82 in startup_children (_pconf=0xb86280a8, plog=0xb865a170, 
s=0xb862c8e8) at /build/buildd/apache2-2.2.14/server/mpm/prefork/prefork.c:776
#17 ap_mpm_run (_pconf=0xb86280a8, plog=0xb865a170, s=0xb862c8e8) at 
/build/buildd/apache2-2.2.14/server/mpm/prefork/prefork.c:997
#18 0xb76c6a92 in main (argc=3, argv=0xbfe750b4) at 
/build/buildd/apache2-2.2.14/server/main.c:742

Original comment by mike.fos...@gmail.com on 12 Dec 2011 at 3:50

[GoogleCodeExporter]

there has been a bug in php which crashed with gc_remove_zval_from_buffer 
(bug #54305)which was fixed with 5.3.7;
does anyone have this problem with a PHP 5.3.7?

Original comment by ppeterma...@gmail.com on 12 Dec 2011 at 4:59

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

The report above came from 5.3.2-1 from the ubuntu 10.04 repos, sorry thought I 
threw the php version in there.

Original comment by mike.fos...@gmail.com on 12 Dec 2011 at 7:46

[GoogleCodeExporter]

A workaround for people who can't change their settings, or have memory limits 
low enough that they still see errors without the PHP bug, is to use the 
attached replacement for the alliance API. It's basically a 3.2.3 version 
modified to work with EDK 4 that uses less memory.

Original comment by kovellia on 18 Dec 2011 at 2:57

Attachments:

• class.alliance.php.zip

[GoogleCodeExporter]

I tried the above workaround, but then the post page also started giving the 
same error.

Original comment by reddrago...@gmail.com on 19 Dec 2011 at 3:35

[GoogleCodeExporter]

Anybody still having this issue with current 4.0.4/4.0.5 or 4.1.0-dev version?

Original comment by hgloc...@gmail.com on 3 Jan 2014 at 3:49