I have a strange problem: I have a PHP application that's working in all common browsers. But some pages are not fully loaded in IE8. If I look at the source code, it has been more ore less randomly cut off and half of the html source is missing, sometimes in the middle of a tag.
The strange thing is, it appears only on some IE-installations (in a big company), on others (I'd say the majority) it's working.
If I look up the apache error logs it says:
[notice] child pid 9393 exit signal Segmentation fault (11)
I don't know if it's related somehow, but how can the same page (called with the same parameters) work on one machine and not on another one (reproducable)?
I have not a single clue if it's some rendering problems in IE, if the browser is crashing internally or if the server really crashes and serving only half of the html source.
(Unfortunately I can't provide an example as it occurs on a web project yet to be released)
Update: I did some testing:
Upgraded Apache2, PHP5, libPHP5 on the Debian machine. Updated, activated, deactivated xdebug, mimicked the request header (user-agent) with apaches mod_header - still the same problem. Honestly I'm not sure, if the seg fault has something to do with the problem that IE only delivers half of the content.
Can this also be due to a virus scanner? Does anyone know of circumstances that IE only gets half the source code when there is no server error?
If your Apache logs say one of the worker processes segfaulted, it's not a client-side issue. No matter what the client does, it should not cause the server to crash.
The issue might be related to IE8, but only indirectly - IE8 could issue a different pattern of requests when visiting the page, or at the very least sends a different User-Agent string which the server might use to follow a different codepath.
Try upgrading your version of Apache. If that doesn't work, check for configuration errors in Apache, such as a bad extension module. If that doesn't do it, inspect your server hardware for flaws.
Sorry, no answer, bt if it were me I'd....
1) configure the php to do an auto-prepend (unless there's already one in place
2) write an include file to trap incomplete page loads (have a llok at ignore_user_abort, connection_status and register_shutdown_function)
If your code can detect occurrences of the problem, then its not related to the segfault.
You might also try installing mod_security which can log post vars and record a log entry at the start of a request - so you have some scope for investigating the segfaults.
After days of debugging (updated server software, moved to another machine and so on) we finally got the problem. It was a very old installation of the Novell Border Manager, some sort of proxy. The segmentation fault seems to be unrelated to this.
If anyone has similar problems, here are two related posts:
http://www.novell.com/support/search.do?cmd=displayKC&docType=kc&externalId=7007318&sliceId=1&docTypeID=DT_TID_1_1
http://forums.novell.com/novell-product-support-forums/access-manager-3/428004-access-manager-showing-partial-content-page-post2058485.html
Related
I just fixed a problem but do not exactly understand why the solution works.
Setting:
Windows 10
Laravel 7.0
PHP built in server (via php artisan serve --port=80)
Hosts file with entry 127.0.0.1 something.local
Problem:
Making a web page request to http://something.local in the browser took very long to load. Upon inspection in chrome dev tools I found out that it is not the server but the actual content download.
Although we are talking about ~7MB to download a download time of >10sec seemed insane to me.
Solution that I do not really understand :
Changing the hosts file entry to 127.0.0.1 something.habibi fixed it for me.
Why does it take so long to download a web page if I use an entry ending in .local in my hosts file?
Thoughts:
.local is not a top level domain but a special-use domain. It seems to me that because of this the request to a url ending in .local might not stay on my machine but goes through my wlan/router somehow and thus takes longer.
But this is as far as I got. It would be nice if someone can make better sense of this behaviour.
Unfortunately I can not make the special behavior of a special-use domain any clearer to you as this is not my forte at all.
But:
Do you - by any chance - have a chrome extension called "Xdebug helper" installed?
If this chrome extension would be the actual cause of your problem than your solution makes sense: changing the url in the browser has the effect that the Xdebug helper extension does not debug this new url you just put in.
Therefore you might think that your problem is caused by the different ending (switching from ".local" to ".habibi") but in reality it is just this chrome extension that gets disabled for the new url.
So long story short: your question is not reproducible and thus can't really be answered.
By the way: Others seem to have the same problem.
I recently ditched XAMPP on my Windows 10 machine and re-installed Apache (2.4), PHP 7 and MySQL manually (I followed the instructions given here in order to be able to switch between PHP versions easily).
Everything works fine, except that now when I make a change in a PHP file and hit Refresh in the browser, the change often doesn't appear immediately in the browser. No matter how hard I hit F5 (or Ctrl+F5), I still get the non-modified source code, and I have to wait a couple of minutes before those change are finally visible to the browser.
Needless to say, it's quite annoying when developing. And it didn't happen when I was using XAMPP.
So there seems to be some kind of cache somewhere, but I can't find where it is. I don't know if it's Apache or PHP, although I suspect it might be PHP, because the CSS or JS files are not affected by this problem (as far as I can tell).
Any idea what's causing this behavior and how to disable it?
EDIT: I did some more testing.
I created the simplest PHP file possible. Just:
<?php
echo 'test1';
I can confirm that the problem occurs even in this simple case (changing "test1" to "test2": the browser still shows "test1" for a while).
Opening the same page in another browser still shows the outdated code (test1 instead of test2).
Clearing the browser cache doesn't help.
So the problem doesn't seem to happen on the client side.
However, if I do the same test with an HTML file instead of a PHP file, then the problem doesn't occur. Any change done to that file is visible immediately in the browser (of course I'm still accessing this file via Apache, so http://localhost/some-path/test.html)
So the problem seems to affect only PHP files.
It seems the problem was caused by the OPCache module, which I had to enable in order to work on another (drupal 8) project.
In php.ini, the following line:
; How often (in seconds) to check file timestamps for changes to the shared
; memory storage allocation. ("1" means validate once per second, but only
; once per request. "0" means always validate)
opcache.revalidate_freq=60
Changing 60 to 1 (and restarting Apache) basically solved the problem.
OS: Windows 7 - 64 bit
PHP: Standalone php.exe (PHP ver 5.5)
PHPStorm
Version: 10.0.1
All the advice I see on getting past the 502 Gateway error in PhpStorm involve just making sure you've got your Interpreter and executable set. I'm using the standalone php.exe (http://windows.php.net/download#php-5.5 VC11 x86 Thread Safe (2015-Oct-01 01:25:56)) and have everything set to PHP 5.5
I am honestly confused why I'm still getting 502 errors.
I've run it multiple times, and it did run once (there were no changes from instances before or after) which I found profoundly odd, but only for one page load and it was not a repeatable occurrence.
Edit: Realized one difference when I opened up another project to compare to. The one time it did work, the right-click context menu looked different. The other project is debugging just fine. What makes the difference? What gives? Both projects are using the same interpreter.
... Also found that going back to the working project, the additional context menu item disappeared.
Edit 2: Still problem hunting... found that certain files will run right when I start PHPStorm and will have that context menu. Other files, however, won't at startup of PHPStorm. If I I try to debug a file without the addtional menu, the server will give 502 and then the "good" files won't have the extra menu. If I start with one that has the extra context menu first, it will run, although if I follow with one doesn't, the first file ceases working. I feel like I'm making "progress" but I am also getting more confused, especially since each of these times I try to run a different file, it asks me "[x] is a single-instance run configuration. Are you sure you want to stop the running one?" At which point I click "Stop and Rerun". I would figure that the ones giving 502 wouldn't have anything carrying over to the "good" files if things are stopped and rerun... but that appears to not be the case.
Edit 3:
Wondered if maybe my interpreter setup might be bad, so I grabbed securewamp ( http://securewamp.org/en/ ), got the portable version, setup, used default setup with xdebug added on (this version: php_xdebug-2.4.0rc1-5.4-vc9.dll) and exact same problem.
I'm even at a loss of additional things to check.
Edit 4: Extra sure that it's something in PHPStorm now. One of the php files that wasn't ever working, I opened directly with the php.exe and it worked fine. It has to be some setting in phpstorm that I"m missing, or some broken function.
Edit 5: Following a trail of potential causes, tried the Run > Validate Debugger tool. Path and URL left to default (no reason to change them), and attempt to vlaidate results in "Please check that web path to validation script is correctly configured" and lists my directory.
Edit 6: Validation was only picking up on 127.0.0.1 because that's what SecureWAMP was running on. Turning off its server results in "failed to execute validation script: 'Connection refused: connect'.
Edit 7: As pointied out by LazyOne, my files in the first image are two different filetypes (php and html). I have done it with .php files on both sides, I just grabbed two of the files I was currently working in for the screenshot. Here's an example of one of the php's.
Edit 8: I think I'm finally getting a solid pattern to when it works and when it doesn't.
The context menu thing was a red herring. Ones without a submenu will work just fine when conditions are met.
A. A file that works (so far no pattern noticed yet for working files vs nonworking, in fact, one working and one nonworking file have the exact same code) must be selected.
B. Cannot, under any condition, "Stop and Rerun" a file as this will cause the file to hit bad gateway afterwards.
C. You can't open up a nonworking file. If you do, current server hangs and will continue to hang until a "stop and rerun" is run on a different file, after which all open files will get the bad gateway error. Opening a non-working file will cause currently working files to get the bad gateway error.
D. To get working files working again after C or D requires restarting system.
Edit 9:
Was fiddling around with the validate debugger configuration tool, and finally got it to give me a different answer (feel silly for it, actually, just had to include the targeted directory in the url to the validation script even though I thought the site was hosting straight from that directory. Oh well. Anyway, had one error, not sure if it's the cause of my issues or not, but will research it.
Edit 10:
Adding to php.ini to address above error...
xdebug.remote_enable=1
Edit 11: No real benefit seen from the added line.
Edit 12: Posting requested screenshot of browser
Edit 13: Updates to the EAP (10.0.2) version of phpStorm. It appears the same result so far, although now at least the console is showing me the error too instead of just the webpage. Also tried running completely through SecureWAMP's apache server only to find out there's something blocking me from changing away from the default htdocs directory.
FWIW, I think this could be as simple as a timing-out problem.
My environment is very similar to the OPs, Win764, PhpStorm 10.0.4, PHP 5.5.27.
I have some F3 automated tests where I see the 502 Bad Gateway error frequently when I run the test code 'in the browser' using one of the little icons in the toolbar that floats to the upper right of my code. (See image below.)
For some of my test pages, the error seems to be first-time-only. Run once, fails, run again, works ok. Others seem to require 2 or 3 runs before they will work. But I have a couple that I've never seen work in the browser.
OTOH, if I right-click in the code window for any of these pages and debug, the code runs fine whether I let it run all the way through or walk it line by line.
Clearly, my tool setup is not wrong. Some tests can and do run from the browser every time.
What I THINK is happening is that the likely-to-fail tests execute fairly heavy db queries. And my php interpreter is aggressively timing out my requests when I run them in the browser.
But, each time a page runs and times out, one or more of its queries gets cached and the next time I run it, the page is faster. Eventually, for the ones that will run at all, enough of the db work is cached so the page can get in under the wire and finish before the time limit.
So that's my theory. What I haven't found is where and how to change the interpreter timeout interval. That is, the timeout interval when run from PhpStorm. I do already have
max_execution_time = 300
in my php.ini file and can see that it is set when I use phpinfo(). But I have to believe that it is getting overridden when the interpreter is run from PhpStorm.
Update -- possible fix: So even though my php.ini file has that max_execution_time setting, I tried looking at my php interpreter settings as described on this PhpStorm support page, steps 1 and 2. There my max_execution_time was 0. So, I added a setting for it using the UI on that page to be the same 300 I have in my php.ini. (Then I closed and re-opened PhpStorm -- a big of old-programmer paranoia.) So far, I've seen one bad gateway message on my 'worst' page but even it ran the second time. The others seem to all be running to completion. I'll do some watchful waiting and see if this 'fix' does me any good long term.
(And, before anyone feels compelled to point it out: Yes, caching queries is a terrible idea for automated tests. Gotta fix that -- but only after I figure out how to extend the interpreter timeout so my tests can succeed without caching.)
This does not directly answer the question, but might be useful to people stumbling on the 502 Bad Gateway error.
Another way of getting a 502 Bad Gateway error is when a php scripts emits too much errors/warnings/notices. I had a script that was generating thousands of notices because of uninitialised variables that would lead to the 502 Bad Gateway error.
One solution is to fix the php code generating those notices or alternatively, disabling notice reporting in the php.ini file by adding & ~E_NOTICE to the error_reporting setting.
For example
error_reporting=E_ALL & ~E_DEPRECATED & ~E_STRICT & ~E_NOTICE
I think I may have found a bug in PHP's crypt() function under Windows.
However: I recognize that it's probably my fault. PHP is used by millions and worked on by thousands; my code is used by tens and worked on by me. (This argument is best explained on Coding Horror.)
So I'm asking for help: show me my fault. I've been trying to find it for a few days now, with no luck.
The setup
I'm using a Windows server installation with Apache 2.2.14 (Win32) and PHP 5.3.2. My development box runs Windows XP Professional; the 'production' server (this is an intranet setup) runs Windows Storage Server 2003. The problem happens on both.
I don't see anything in php.ini related to crypt(), but will happily answer questions about my config.
The problem
Several scripts in my PHP app occasionally hang: the page sits there on 'waiting for localhost' and never finishes. Each of these scripts uses crypt to hash a user's password before storing it in the database, or, in the case of the login page, to hash the entered password before comparing it to the version stored in the database.
Since the login page is the simplest, I focused on it for testing. I repeatedly logged in, and found that it would hang maybe 4 out of 10 times.
As an experiment, I changed the login page to use the plain text password and changed my password in the database to its plain text version. The page stopped hanging.
I saw that PHP's latest version lists this bugfix:
Fixed bug #51059 (crypt crashes when
invalid salt are [sic] given).
So I created a very simple test script, as follows, using the same salt given in an official example:
$foo = crypt('rasmuslerdorf','r1');
echo $foo;
This page, too, will hang, if I reload it like crazy. I only see it hanging in Chrome, but regardless of browser, the effect on Apache is the same.
Effect on Apache
When these pages hang, Apache's server-status page (which I explained here, regarding a different problem) increments the number of requests being processed and decrements the number of idle workers. The requests being processed almost all have a status of 'Sending Reply,' though sometimes for a moment they will show either 'Reading request' or 'keepalive (read).'
Eventually, Apache may crash. When it does, the Windows crash report looks like this:
szAppName: httpd.exe
szAppVer: 2.2.14.0
szModName: php5ts.dll
szModVer: 5.3.1.0 // OK, this report was before I upgraded to PHP 5.3.2,
// but that didn't fix it
offset: 00a2615
Is it my fault?
I'm tempted to file a bug report to PHP on this. The argument against it is, as stated above, that bugs are nearly always my fault.
However, my argument in favor of 'it's PHP's fault' is:
I'm using Windows, whereas most servers use Linux (I don't get to choose this), so the chances are greater that I've found an edge case
There was recently a bug with crypt(), so maybe it still has issues
I have made the simplest test case I can, and I still have the problem
Can anyone duplicate this? Can you suggest where I've gone wrong? Should I file the bug after all?
Thanks in advance for any help you may give.
The bugs 51059 (only about passing invalid inputs) or 50947 (not the same code, 5.3 has new algorithms and features implemented in php, on all platforms) are not related to this problem.
However http://bugs.php.net/bug.php?id=51424 is. I already posted a partial patch there, but it solves most of the possible locks but it is indeed not sufficient. A full fix will be present in the next 5.3 release.
By the way, it is not windows specific but about the threaded SAPI (windows apache 2.2 for example).
This question has now been viewed 128 times and upvoted 9 times. The only answer I've received says it's a bug, and points to one in the PHP bug database. I don't think it's exactly the same one, but it does seem to validate my diagnosis.
Therefore, with some hesitation, I have filed a bug report:
Bug #51666 - Using crypt() makes Apache hang or crash
Thanks to everyone who has looked at this with me - even if you didn't reply, just knowing that others were considering this with me, and not telling me I'm crazy, has been helpful.
Yes. It's a known bug,
http://bugs.php.net/bug.php?id=50947
You can simulate the crypt() result using mcrypt. If you can change your password hash, you should really use hash_hmac(), which is more secure and we have no issues with it On Apache. No experiences on Windows though.
I am calling a PHP-Script belonging to a MySQL/PHP web application using FF3. I run XAMPP on localhost. All I get is this:
Connection Interrupted
The connection to the server was reset while the page was loading.
The network link was interrupted while negotiating a connection. Please try again.
There are a number of possible solutions ... depends on the "why" ... so it ends up being a bit of trial and error. On a fresh install, that's tricky to determine. But, if you made a recent "major" change that's a place to start looking - like modifying virtual hosts or adding/enabling XDebug.
Here's a list of things I've used/done/tried in the past
check for infinite loops ... in particular looping through a SQL fetch result which works 99% of the time except the 1% it doesn't. In one case, I was using the results of two previous queries as the upper and lower bounds of a for loop ... and occasionally got a upper bound of a UINT max ... har har har (vomit)
copying the ./php/libmysql.dll to the windows/system32 directory (Particularly if you see Parent: child process exited with status 3221225477 -- Restarting in your log files ... check out: http://www.java-samples.com/showtutorial.php?tutorialid=1050)
if you modify PHP's error_reporting at runtime ... in certain circumstances this can cause PHP to degenerate into an unstable state if, say, in your PHP code you modify the superglobals or fiddle around with other deep and personal background system variables (Nah, who would ever do such evil hackery? ahem)
if you convert your MySQL to something other than MyISAM or mysqli
There is a known bug with MySQL related to MyISAM, the UTF8 character set and indexes (http://bugs.mysql.com/bug.php?id=4541)
Solution is to use InnoDB dialect (eg sql set GLOBAL storage_engine='InnoDb';)
Doing that changes how new tables are created ... which might slightly alter the way results are returned to a fetch statement ... leading to an infinite loop, a malformed dataset, etc. (although this change should not hang the database itself)
Other helpful items are to ramp up the debug reporting for PHP and apache in their config files and restart the servers. The log files sometimes give a clue as to at least where the problem might reside. If it happens after your page content was finished it's more likely in the php settings. If it's during page construction, check your PHP code. Etc. etc.
Hope the above laundry list helps somebody someday ... probably myself when I run into it again and come back here looking for "how the heck did I fix it last time?" ... :)
It's possible that your script could be caught in an infinite loop. If that doesn't apply, then I'd check the error logs like TimB suggested.
It sounds like the PHP script you're calling is failing without returning a valid response. Depending on the level of logging that you have set up, this should generate an error in the Apache logfile, which will give you some idea of the problem. I'm not familiar with XAMPP, but you should be able to find out where the logs are, and look for an error that occurred at the time you made your request to the PHP script.
copying libmysql.dll to apache\bin folder may help you overcome this strange error
I solved this problem Upgrading the xampp\php\ext\xdebug\php_xdebug.dll
(changed to php xdebug v.2.0.5-5.3-vc9 )
I had the same problem and this is what i did.
I issued the http get command through php cli script, and as it turns out I had declared one class twice somewhere.
By the way , i use AMPPS on an mac
Hope this helps some one!
Try doing the request with Firebug enabled and see what info you can get out of that; I always find that using wget is helpful for seeing the raw HTTP interaction without worrying about Firefox's UI elements interfering.
If you are using certificates for ssl in Windows 2008 Server(iis 7) from old selfssl tool(iis 6), that is the problem. Sometimes Microsoft releases patches which can destruct all these old certificates. The solution is to generate them again.
copying libmysql.dll to apache\bin folder may help you overcome this strange error
Indeed this helped me to solve this problem
The connection to the server was reset while the page was loading.
Incase the issue is not working this did the trick for me.
1. I got a new zip directory for PHP and connected it with apache
2. I searched for the libmysql in the new php and inserted this to the apache/bin
its this libmysql.dll that is needed there and not the one form mySQL/bin.
ok at least thats the one that worked.
I experienced a very similar issue - which doesn't apply to the person who asked this question - but may be of help to others who are reading this page...
I had an issue where in certain cases PHP 5.4 + eAccelerator = connection reset. There was no error output in any log files, and it only happened on certain URLs, which made it difficult to diagnose. Turns out it only happened for certain PHP code / certain PHP files, and was due to some incompatibilities with specific PHP code and eAccelerator. Easiest solution was to disable eAccelerator for that specific site, by adding the following to .htaccess file
php_flag eaccelerator.enable 0
php_flag eaccelerator.optimizer 0
(or equivalent lines in php.ini):
eaccelerator.enable="0"
eaccelerator.optimizer="0"