I recently installed mountain lion, and when I went to start apache from XAMPP I got an error requesting I disabling web sharing in order for XAMPP to work. After some research I found a command which would turn of the apache that comes bundled with mountain lion. This worked and apache from XAMPP started.
However the next thing I have noticed is im no longer getting error handling.
Im using fuelphp, however instead of an error message when there are issues with my code I get a blank page with the words NO DATA RECEIVED :S.
For example removing a ; from the end of line, results in the above opposed to a readble error message.
I checked the frameworks index.php file which has error reporitng on
error_reporting(E_ALL);
ini_set('display_errors', 1);
Could any one give me a step by step explanation of how to get my error reporting back :'(
I have the same problem on Max OS X too. It's definitely a server configuration issue as exactly the same code works perfectly well on Windows and multiple Linux environments.
My Apache/PHP was installed on the Mac through XAMPP. Others who are suffering from the same issue, please let me know in the comments if you too are using XAMPP. I want to track down the exact server config that is causing this problem.
For now, I have a hacky workaround:
In fuel/core/bootstrap.php, add this to the top of your register_shutdown_function
$last_error = error_get_last();
if (is_array($last_error) && \Fuel::$env == \Fuel::DEVELOPMENT && in_array($last_error['type'], array(4, 1, 256, 64))) {
exit();
}
Weird thing is though, it's hit and miss as to whether it catches the error. So I sometimes have to refresh a few times.
Oh and you must set the environment to DEVELOPMENT. This is to stop leaking errors in production deployed sites.
EDIT:: It seems that MAMP (latest version 2.1.2 at time of writing) does not suffer from this issue. Neither does XAMPP 1.8.1-beta1. So you could also try using those.
Related
Just for the record, here's the error I'm getting (don't stop reading there):
Oops! An Error Occurred The server returned a "500 Internal Server Error".
Something is broken. Please let us know what you were doing when this error occurred.
We will fix it as soon as possible. Sorry for any inconvenience caused.
Before you jump to the usual conclusions, let me tell you that I traced the error to; a line like:
throw new \Exception("Some value not recognized: $someVar");
Normally Exceptions work fine; I can't tell why this one's so weird.
$someVar isn't storing anything weird, just a string like "Hi, I am a string". The Exception running actually makes sense with the input I tested. What I'm unable to figure out is why the 500 error is happening, and why there's no logs for it, and why anything I try doesn't solve the problem or give me any clue what to do next.
I already tried enabling PHP errors, across many files, even up to the line right before the Exception line:
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);
MAMP's Apache logs and PHP logs show nothing for it, just earlier unrelated stuff.
MAMP appears to not have its own log files, so I can't see what's actually failing.
For some reason, something is triggering the 500 error, and all I'm seeing is another brick in the wall.
My MAMP Pro (paid) version is 6.6.2, my macOS is Monterey, Apache 2.4, PHP 7.4 (sorry, we're trying to upgrade), and everything's been working fine until today.
So I was updating our web servers (Windows 2012 R2/IIS) with the newest version of PHP this morning (version 7.4.8 from 7.4.6, because I was slacking 2 weeks ago).
In our setup, we include the dll from Microsoft (php_pdo_sqlsrv_74_nts.dll) in the ext folder as we have some sites running some PDO lookups to some backend SQL servers. After I registered the new version, I started getting errors in those PDO calls (PDO is loading), but I'm getting cannot find driver. As soon as I switch back over to 7.4.6, everything loads.
I didn't see a newer file provided from Microsoft yet. Is anyone else seeing this behavior or have a fix for it yet?
Thanks,
Since I had more then one php version installation.I had to specify the specific extension folder in my php7.4.8 ini file. i.e.extension_dir = "C:/php7.4/ext"
Everything worked fine after that
Since there could be multiple PHP version side-by-side.
1.Please ensure your IIS PHP-CGI handler is pointing to the right version.
2.Please ensure you have copy the dll to the right ext folder
3.Please ensure you have set the correct extension_dir
4.Please ensure you have registered the extension=..... correctly.
5.Please do an IISRESET when you finish updating the configuration.
You can try to double click php-cgi.exe to check the real exception. If everything is set correctly, there might be some compatibility issue.
Have you tried to double click php-cgi.exe to check the real
exception? If there is a issue, there should be an error message. Have
you encountered any error message?
No error after double clicking php-cgi.exe
So this was eventually fixed in the release of 7.4.10. It was a little known error it seems, but they got it fixed.
I'm trying to get xdebug working on my Mac. I'm using OS 10.6 with the built-in versions of Apache (2.2.1) and PHP (5.3.8). I followed the "tailored installation instructions" on the xdebug website, which basically consisted of these steps:
Build xdebug (version 2.1.3) from source
Move xdebug.so to /usr/lib/php/extensions/no-debug-non-zts-20090626
Add to php.ini:
zend_extension = /usr/lib/php/extensions/no-debug-non-zts-20090626/xdebug.so
Restart the webserver.
From what I understand, that should be it. I know most people use xdebug with an IDE like PHPEclipse, but it doesn't sound like that's necessary just to get debugging output on the page. And a lot of old instructions involve installing MAMP, but it looks like that's no longer necessary.
Signs xdebug is working: When I run php -m and phpinfo() I get the expected information on xdebug. In scripts I'm able to call functions like xdebug_is_enabled() (returns 1) and xdebug_get_function_stack() (returns the stack).
Ways xdebug is not working: The main reason I installed xdebug was to get a stack trace when there's an error, and that's not happening. According to this documentation page, I should get a stack trace as long as display_errors is set to On in php.ini, (which it is). I've tried code that should evoke a warning (e.g., echo(hello)) as well as code that produces a fatal error (e.g., $x->awesomefunction() when $x isn't an object). Neither one produces any xdebug output, and the fatal error just causes the page to die silently. The test code given in the documentation I linked to also produces nothing.
UPDATE: It turns out that if I run a script with a fatal error from the terminal, I do get a stack trace from xdebug. However, it's still not showing up when I run the script from a browser
Also, regular error reporting is now broken: Previously, I'd get error output by including the commands:
ini_set("display_errors","1");
ERROR_REPORTING(E_ALL);
Now, putting those lines in my script doesn't produce any error reporting either. (in the browser. It does cause errors to be shown when I run the script from the terminal.)
So, what's wrong here? Did I leave something out of the xcode installation? Do I have a setting hanging around somewhere else on my system, suppressing errors? I've tried everything I can think of, but I'd be happy to test any ideas you have.
If it is working on console and not on browser, it's probably a xdebug configuration issue.
I'm not a Mac user, but on Ubuntu there are 2 different php.ini files, one for console and one for apache. If that's the case for Mac also, you can check if xdebug is enabled and properly set up in both php.ini files.
Also you can check the xdebug settings mentioned in the guide.
After several more hours of thrashing, I discovered that one of my test files actually was including another file that set display_errors to 0. The other test file was straight off of the xdebug site, but I think that at the time I was using it I'd introduced some other config error that prevented it from working properly. I'm truly embarrassed! Let this be today's object lesson in the importance of systematic, repeatable tests during debugging. On the bright side, xdebug is now working like a peach.
To summarize, the series of steps that worked was:
Build xdebug (version 2.1.3) from source
Move xdebug.so to /usr/lib/php/extensions/no-debug-non-zts-20090626
Add to php.ini: zend_extension = /usr/lib/php/extensions/no-debug-non-zts-20090626/xdebug.so
Add to php.ini: display_errors = On
Restart the webserver.
Wondering if someone can help...
I am running PHP 5.3.6, on Windows Server 2008 R2, with IIS 7.5 & Helicon APE (Apache module for .htaccess files)
I have a legitimate serial number from socialengine.net (although my support tickets have expired.)
I downloaded 4.1.8p1 from "My Account" and unzipped directly into the web root (no need to FTP as I'm working directly on the host server)
I went through the install with no probs, everything went as expected.
When I goto "Sign In" or "Sign Up" I get nothing but a blank page. As far as I know all folders that require the 755 equivalent are set. I can upload & activate plugins with no probs etc.
Development mode reveals nothing, and even with all error reporting on in php.ini I still don't get any error... FirePHP doesn't report anything either (except the norm debug info)
I currently have no 3rd party plugins installed, it is a brand new installation, yet the 2 pages just will not work :( :(
Anyone got any ideas on how I can find out what the problem is??
Domain is http://dance-network.net
Many thanks in advance!
Proof of purchase
A blank page usually means a PHP script error. We suggest going through the code of the page that is not showing up and trying to print errors with:
ini_set('display_errors', 'on');
error_reporting(E_ALL);
However some servers (such as the ones that run on Parallels Plesk) have error reporting disabled. We suggest enabling error reporting or going through line by line with print statements to see where the error might be occurring.
UPDATE (5/21/2010) SUCCESS!
So after MUCH $head->desk()'ing, I've solved it.
Remember kids, be wary of the instant client version you use, dependent on the virtualization settings!
I had been installing the generic Instant Client (not aware our ESX servers sit on AMD processors, not Intel) and that worked fine internally (the CentOS install was 32-bit since our internal ESXi servers aren't 64-bit). Well lo-and-behold, even if you have a 32-bit install running on a virtualized server which is sitting on an AMD64, it still matters what instant client you install.
It was the last thing I thought to check but as it appears, everything is running fine now.
I would like to thank everyone who helped me run through every possible test to figure this out but in the end, it was my fault for not realizing the differences in the virtualizations.
UPDATE (5/21/2010)
I thought this bug had escaped me when I installed it on a new VM internally but I have now found a narrowing link.
I was trying to install this on our production server when I posted this. After a week of no progress and in need to get back to development, I outfitted a VM on our internal server with a brand new install of Crap... CentOS, and fresh installs of instant client and oci8.
Worked perfectly.
However we just uploaded an exact copy of the VM to our production servers and it magically no longer works. Tried reinstalling everything, no avail.
So the only things I could narrow it down to is a firewall issue (although I get the same issue when trying 127.0.0.1) or possibly an ESX (our production servers) server issue, internal servers are running ESXi.
Any thoughts?
UPDATE (3/8/2010) I installed Xdebug and have it tracing my code. This is the output I am getting:
TRACE START [2010-03-08 17:53:05]
0.2090 327864 -> {main}() /data/aims3/http/octest.php:0
0.2091 327988 -> ini_set(string(14), string(1)) /data/aims3/http/octest.php:3
0.2093 327920 -> error_reporting(long) /data/aims3/http/octest.php:4
0.2094 328048 -> oci_connect(string(8), string(8), string(25)) /data/aims3/http/octest.php:6
The trace halts at that point.
I have installed everything the same way on a local server and it works fine. To say I am at a complete loss would be putting it lightly.
*NOTE: I ran make test and it returned FAIL on every test. I never ran this on my working machine to see if it reports the same errors. Any idea why make test would report FAIL but make doesn't report any error?
I've installed the Oracle Instantclient with no reported errors along with the OCI8 PECL package and at a loss. Whenever I try to open a connection with oci_connect, it halts my entire PHP script.
EXAMPLE:
<?php
ini_set ("display_errors", "1");
error_reporting(E_ALL);
echo "before";
$conn = oci_connect("username", "password", "host");
echo "after";
?>
Returns a complete blank page. The module is loaded (seen in phpinfo) and everything installed with no errors.
I am at a complete loss.
CentOS: 5.4
Apache: 2.2.3
PHP: 5.3.1
InstantClient: 11.2
oci8: 1.4.1
Any thoughts?
NOTES
Apache Error Log reports nothing
Attempted Debugging:
1:
<?php
ini_set ("display_errors", "1");
error_reporting(E_ALL);
echo "before";
if(!function_exists('oci_connect')) die('Oracle Not Installed');
echo "after";
?>
Returns:
beforeafter
2:
Changing host to //host
Returns:
Same error
Is there anything in Apache's error_log? Is this mod_php or FastCGI or normal CGI PHP? What happens if you run the script via the command line?
You could also try setting PHP's error log and looking in there.
EDIT1: Try:
echo "before";
if(!function_exists('oci_connect')) die('Oracle Not Installed');
And post the results...
EDIT2: I'm really not sure. My best bet is this info from the PHP manual:
The most common problem with
installing OCI8 is not having the
Oracle environment correctly set. This
typically appears as a problem using
oci_connect() or oci_pconnect(). The
error may be a PHP error such as Call
to undefined function oci_connect(),
an Oracle error such as ORA-12705, or
even an Apache crash. Check the Apache
log files for startup errors and see
the sections above to resolve this
problem.
Anyone else have any ideas to help out Bryan?
Bryan,
I am going to be honest: I tried this two years ago and failed miserably. :) I could not get the OCI functions to work for anything by compiling myself.
But in the interest of getting it done I looked for an alternate solution and found it in Zend Core for Oracle. All I did was download, run the installer, and it was done. It installs Apache/PHP, MySQL (optional), and the InstantClient for you.
Now as Zend Server, it is basically the same product. I realize that this may not be the solution you hoped for, but if it works...
Zend Server
are you connecting to remote or to local db? i think, for localhost you must replace "host" with "false". I hope, this will help you...
edit: i think, you are missing a parameter...my last suggestions are: 1. you must set the port (default 1521) AND/OR 2. You must enter db name AND/OR you must set the instance name (the ORACLE_SID parameter)
You never check the return value of oci_connect() or call oci_error() but it doesn't look relevant to your problem since you seem to be suffering from a PHP crash. There's an open bug for RHEL that may affect you too:
http://pecl.php.net/bugs/bug.php?id=16626
Did you build the oci8 package yourself? Are you using a third-party binary?
It has been fixed. See the top for details but here is the cliff notes: virtualiztion environments matter.