php-general Digest 23 Jun 2011 23:04:42 -0000 Issue 7372
Topics (messages 313675 through 313684):
Re: URL Rewriting
313675 by: Geoff Lane
Memory limit Problem
313676 by: Graham Drabble
313677 by: Peet Grobler
313678 by: james.nixsecurity.org
313679 by: Graham Drabble
Re: Create a hierarchical hash from flat source
313680 by: Tamara Temple
313682 by: Robert Cummings
Re: jQuery to PHP
313681 by: Tim Streater
php session_start dead lock
313683 by: Zaccone, Warren
313684 by: Daniel Brown
Administrivia:
To subscribe to the digest, e-mail:
[email protected]
To unsubscribe from the digest, e-mail:
[email protected]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
On Thursday, June 23, 2011, Ashley Sheridan wrote:
> I've not yet seen any evidence yet that pretty URLs actually benefit
> SEO. I regularly search for answers to problems online, and mostly I
> get forums as the results, all of which have URLs like
> showthread.php?t=1234567
Anecdotal perhaps, but I see the opposite. Most of what I see 'above
the cut-line' in search results doesn't have a querystring and the
forums at the top of the list mostly seem to be rewritten. For
example, in a recent search on Google.co.uk for "pusher aircraft", the
first page except for the last result were all 'SEO-friendly' URLs.
The last but one returned result was an obviously rewritten forum post
http://www.theaerodrome.com/forum/2001/11195-pusher-aircraft.html The
first returned result with a querystring was a YouTube video.
I also tried searching for something about which I'm fairly confident
that the majority of information 'out there' is contained in forum
posts and although the second result on the first page was a forum
post, all but three on the first two pages had no querystring.
That said, the reason I use rewriting is because it makes site
maintenance much easier for me rather than because of any SEO benefit
- real or imagined.
--
Geoff
--- End Message ---
--- Begin Message ---
Hi,
I've got a problem with setting the memory limit in php.ini.
I have
memory_limit = 1024M ;
set in php.ini
Checking with phpinfo says I have
memory_limit 1024M 1024M
However when uploading a large file I get
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate 81439166 bytes)
(ie it seems I only have 128M available).
There's plenty of RAM on the server.
Any ideas?
--
Graham Drabble
http://www.drabble.me.uk/
--- End Message ---
--- Begin Message ---
On 6/23/2011 3:29 PM, Graham Drabble wrote:
> (ie it seems I only have 128M available).
>
> There's plenty of RAM on the server.
>
> Any ideas?
Check for the upload_max_filesize parameter.
--- End Message ---
--- Begin Message ---
Check the value of the upload_max_filesize and post_max_size directives in the
php.ini.
>---- Original Message ----
>From: Graham Drabble <[email protected]>
>To: [email protected]
>Sent: Thu, Jun 23, 2011, 9:46 AM
>Subject: [PHP] Memory limit Problem
>
>Hi,
>
>I've got a problem with setting the memory limit in php.ini.
>
>I have
>memory_limit = 1024M ;
>set in php.ini
>
>Checking with phpinfo says I have
>
>memory_limit 1024M 1024M
>
>However when uploading a large file I get
>
>Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
>allocate 81439166 bytes)
>
>(ie it seems I only have 128M available).
>
>There's plenty of RAM on the server.
>
>Any ideas?
>--
>Graham Drabble
>http://www.drabble.me.uk/
>
>--
>PHP General Mailing List (http://www.php.net/)
>To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
On 23 Jun 2011 [email protected] wrote in
news:[email protected]:
>
> Check the value of the upload_max_filesize and post_max_size
> directives in the php.ini.
>From phpinfo()
upload_max_filesize 800M 800M
post_max_size 1000M 1000M
(fwiw the file I'm uploading is ~85MB)
--
Graham Drabble
http://www.drabble.me.uk/
--- End Message ---
--- Begin Message ---
On Jun 22, 2011, at 5:24 PM, Scott Baker wrote:
On 06/22/2011 03:17 PM, Simon J Welsh wrote:
You still need to pass the value by reference to assign_children(),
so:
$new = &$leaf[$pid];
assign_children($pid,$list,&$new);
One last thing I fixed was that PHP was complaining that run-time pass
by reference was deprecated. I changed assign_children to be
function assign_children($id,$list,&$leaf)
Which solved that also!
Ah, pointers, how we love them. The bane of every CS undergrad.
--- End Message ---
--- Begin Message ---
On 11-06-23 12:54 PM, Tamara Temple wrote:
On Jun 22, 2011, at 5:24 PM, Scott Baker wrote:
On 06/22/2011 03:17 PM, Simon J Welsh wrote:
You still need to pass the value by reference to assign_children(),
so:
$new =&$leaf[$pid];
assign_children($pid,$list,&$new);
One last thing I fixed was that PHP was complaining that run-time pass
by reference was deprecated. I changed assign_children to be
function assign_children($id,$list,&$leaf)
Which solved that also!
Ah, pointers, how we love them. The bane of every CS undergrad.
Bane? I thought they were elegant :)
Cheers,
Rob.
--
E-Mail Disclaimer: Information contained in this message and any
attached documents is considered confidential and legally protected.
This message is intended solely for the addressee(s). Disclosure,
copying, and distribution are prohibited unless authorized.
--- End Message ---
--- Begin Message ---
On 23 Jun 2011 at 14:56, Ethan Rosenberg <[email protected]> wrote:
> At 05:21 PM 6/22/2011, you wrote:
>> 2) Instead of doing alert("yippee"), seems to me you should alert on
>> the results of the ajax call. I don't know how you get at those with
>> jquery, but I imagine that is where you'll find the results of doing
>> var_dump($_POST);
> The results should be in $_POST. I have done a print_r and var_dump
> and nothing is there. My question was if the call ever worked.
But you don't know that nothing is there because you haven't looked for the
output.
When an ajax call is made, it causes a script on the server to be run. You tell
the ajax call what script you want to have run, in this case apparently
jq_test.php. All output from that script will be returned to the function you
specify in the ajax call. As I said, I don't know jquery, but I'm guessing that
that is the success: function - and in that you do nothing with the returned
results. I should also point out that *all* output from the script will be
returned there. That means anything from an echo or var_dump statement, but
also anything *outside* <?php and ?>, which means all the html that is in your
file jq_test.php too. It's all concatenated together as one humungous text
string and returned to your ajax success: function. And because you're not
looking at those results, you won't see them.
>> 3) Where *are* you expecting the output from var_dump($_POST); to
>> appear, and why?
> As I understand, $.post [which is an Ajax call??] should put the results into
> $_POST in the URL: in the call.
Well, it might put it into $_POST["move_from"], possibly, but I don't know what
the JavaScript behind this jquery call actually does.
>> 5) For a simple but effective ajax example, see
>> http://www.clothears.org.uk.
> Looks good.
Thanks but have you understood it?
>> 6) If you're attaching an onclick to each table cell, the onclick
>> handler can write the cell's id into the form, seems to me. Why use
>> ajax for that?
> Please tell me how to do that [write cell's id into form].
Something like (e.g.):
Move From: <input type="text" name="move_from" id="xyz"></input>
and then in your onclick handler:
document.getElementById("xyz").textContent = this.id;
I'd say also that you need to keep separate your HTML page (where you display
your 8x8 grid and click on the cells) from any PHP scripts you want to run with
ajax.
--
Cheers -- Tim
--- End Message ---
--- Begin Message ---
We recently started experiencing a problem on our server (httpd 2.2.19, PHP
5.3.6) where all of the apache child processes hang in PHP code and no longer
process requests.
I am running Apache as prefork on Solaris 10 with 256 children, and found
that within a few minutes all 256 httpd child processes are stuck, and it's
always in the same place within php_session_start in a php_flock call. Stack
trace is shown below.
The file it is trying to flock is
/var/tmp/sess_2e39aabaf226819b67f29da477892e91.
All 256 httpd child processes show the exact same stack trace. When it occurs
it eventually (after a long time does timeout) and recover - but it may take
over 1 hour. We have to stop and restart the server before that.
pstack 6802
6802: /usr/local/apache/bin/httpd -d /usr/local/apache -f /usr/local/apache/
feccb880 fcntl (12, 7, ffbfe600)
fecbb514 fcntl (12, 1, ff172a00, 7d054, fe7845c4, fed303a8) + 84
fe6f2d88 php_flock (12, 2, 0, 1c80e8, 0, 0) + 58
fe624e38 ps_files_open (1c9af0, 1c80e8, ffffffff, fea76238, 1c6738, 100) + 224
fe625160 ps_read_files (1c9af0, 1c80e8, ffbfeca0, ffbfec9c, 4, fe625148) + 18
fe622984 php_session_start (18, fffb8bf0, ffffffff, b800, b400, b800) + bd0
fe623e34 zif_session_start (0, 1cfeb0, 0, 0, 0, 333f18) + 10
fe7ca6b8 zend_do_fcall_common_helper_SPEC (333460, b400, feb25e18, 33bd78, 0,
0) + 76c
fe7c99e0 execute (feb25e18, 1c8000, 2f, ffbfeed4, 4, feb24d00) + 210
fe7a6494 zend_execute_scripts (8, 1, 3, ffbfef40, feb25e18, ffbff4f8) + 12c
fe74c0c4 php_execute_script (0, feab1f20, 6, 0, 70687000, 0) + 224
fe83a470 php_handler (32d470, 0, 32d470, c2c00, c3ee0, 9) + 2d0
000412c8 ap_run_handler (32d470, 3b3b3b3b, 70687000, 80808080, ff00, 80808080)
+ 3c
0004175c ap_invoke_handler (1668c0, 97400, 32d470, ffbff68c, fddf0028, 0) + c0
0006c890 ap_process_request (32d470, 0, 4, 32d470, 0, 0) + 160
00069964 ap_process_http_connection (3276f0, 327458, 327458, b6, c4740,
e3dc0)+ 10c
00047a60 ap_run_process_connection (3276f0, 327458, 327458, b6, 3254a0,
32b428) + 3c
00087740 child_main (0, 1, c6800, c6c00, 11177, c6800) + 434
000879a4 make_child (87000, b6, 6, 0, d7300, c6800) + ec
000883ac ap_mpm_run (c6800, c4400, aa, c6800, c6c00, c6800) + 91c
0002e2bc main (d17a8, c1800, c3c00, c3c00, cf7a0, 0) + 784
0002d668 _start (0, 0, 0, 0, 0, 0) + 5c
# pfiles 6802
6802: /usr/local/apache/bin/httpd -d /usr/local/apache -f /usr/local/apache/
Current rlimit: 65536 file descriptors
0: S_IFCHR mode:0666 dev:340,0 ino:6815752 uid:0 gid:3 rdev:13,2
O_RDONLY
/devices/pseudo/mm@0:null
1: S_IFCHR mode:0666 dev:340,0 ino:6815752 uid:0 gid:3 rdev:13,2
O_WRONLY|O_CREAT|O_TRUNC
/devices/pseudo/mm@0:null
2: S_IFREG mode:0644 dev:85,0 ino:270102 uid:60001 gid:60001 size:3692960
O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE
/usr/local/apache/logs/error_log
3: S_IFSOCK mode:0666 dev:347,0 ino:32405 uid:0 gid:0 size:0
O_RDWR|O_NONBLOCK
SOCK_STREAM
SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0.0.192.0)
sockname: AF_INET 0.0.0.0 port: 80
4: S_IFDOOR mode:0444 dev:349,0 ino:55 uid:0 gid:0 size:0
O_RDONLY|O_LARGEFILE FD_CLOEXEC door to nscd[170]
/var/run/name_service_door
5: S_IFCHR mode:0620 dev:340,0 ino:12582920 uid:0 gid:7 rdev:24,2
O_RDWR
/devices/pseudo/pts@0:2
6: S_IFSOCK mode:0666 dev:347,0 ino:52766 uid:0 gid:0 size:0
O_RDWR|O_NONBLOCK
SOCK_STREAM
SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152),IP_NEXTHOP(0
.0.192.0)
sockname: AF_INET 0.0.0.0 port: 443
7: S_IFIFO mode:0000 dev:338,0 ino:2827255 uid:0 gid:1 size:0
O_RDWR|O_NONBLOCK
8: S_IFIFO mode:0000 dev:338,0 ino:2827255 uid:0 gid:1 size:0
O_RDWR
9: S_IFREG mode:0644 dev:85,0 ino:270103 uid:60001 gid:60001 size:601185983
O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE
/usr/local/apache/logs/access_log
10: S_IFREG mode:0644 dev:85,0 ino:270103 uid:60001 gid:60001 size:601185983
O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE
/usr/local/apache/logs/access_log
11: S_IFREG mode:0644 dev:85,0 ino:270104 uid:60001 gid:60001 size:2151
O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE
/usr/local/apache/logs/ssl_request_log
12: S_IFREG mode:0644 dev:85,0 ino:270797 uid:0 gid:1 size:0
O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE
13: S_IFCHR mode:0000 dev:340,0 ino:18026 uid:0 gid:0 rdev:21,622
O_WRONLY FD_CLOEXEC
/devices/pseudo/log@0:conslog
14: S_IFREG mode:0644 dev:85,0 ino:270798 uid:0 gid:1 size:0
O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE
15: S_IFPORT mode:0000 dev:350,0 uid:60001 gid:60001 size:0
16: S_IFSOCK mode:0666 dev:347,0 ino:19961 uid:0 gid:0 size:0
O_RDWR|O_NONBLOCK
SOCK_STREAM
SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49640),IP_NEXTHOP(0.0.193.232)
sockname: AF_INET 128.96.156.65 port: 80
peername: AF_INET 128.96.195.58 port: 1672
17: S_IFDIR mode:0755 dev:85,0 ino:2 uid:0 gid:0 size:1024
O_RDONLY
/
18: S_IFREG mode:0600 dev:85,0 ino:759973 uid:60001 gid:60001 size:1072
O_RDWR|O_CREAT
advisory write lock set by process 6706
/var/tmp/sess_2e39aabaf226819b67f29da477892e91
#
fuser -f sess_2e39aabaf226819b67f29da477892e91
sess_2e39aabaf226819b67f29da477892e91: 6885o 6884o 6883o 6882o 6
881o 6880o 6879o 6878o 6877o 6876o 6875o 6874o 6873o
6872o 6871o 6870o 6869o 6868o 6867o 6866o 6865o 6854o
6853o 6852o 6851o 6850o 6849o 6848o 6847o 6846o
6845o...
brief outline of my code is:
session_cache_limiter('nocache');
session_start();
store/retrieve some data from $_SESSION
ob_start();
code to format page to send to browser.
ob_end_flush();
session_write_close();
exit();
I appreciate any advice as to how to avoid this problem, or experiences with it
for my trouble shooting.
thank you.
--- End Message ---
--- Begin Message ---
On Thu, Jun 23, 2011 at 15:27, Zaccone, Warren <[email protected]> wrote:
> We recently started experiencing a problem on our server (httpd 2.2.19, PHP
> 5.3.6) where all of the apache child processes hang in PHP code and no longer
> process requests.
>
> I am running Apache as prefork on Solaris 10 with 256 children, and found
> that within a few minutes all 256 httpd child processes are stuck, and it's
> always in the same place within php_session_start in a php_flock call.
> Stack trace is shown below.
>
> The file it is trying to flock is
> /var/tmp/sess_2e39aabaf226819b67f29da477892e91.
May want to consider fsck'ing that drive, Warren. You may have
some bad clusters that are causing disk I/O issues. Just one of many
possibilities, of course, but the least favorite of all, obviously.
--
</Daniel P. Brown>
Network Infrastructure Manager
http://www.php.net/
--- End Message ---
