I'm encountering a weird problem with couchDB. Some documents in my database can't be updated due to unknown conflicts. When comparing them to other documents in Futon I don't see any big differences to other documents. When I try to update one of those documents the revision number jumps from e.g. 45 to 58 but no changes are visible.
This is what I see in the couchdb log file..
[Tue, 22 Nov 2016 13:45:10 GMT] [debug] [<0.30579.229>] Minor error in HTTP request: conflict
[Tue, 22 Nov 2016 13:45:10 GMT] [debug] [<0.30579.229>] Stacktrace: [{couch_db,update_doc,4,
[{file,"couch_db.erl"},{line,432}]},
{couch_httpd_db,update_doc,6,
[{file,"couch_httpd_db.erl"},
{line,753}]},
{couch_httpd_db,do_db_req,2,
[{file,"couch_httpd_db.erl"},
{line,234}]},
{couch_httpd,handle_request_int,5,
[{file,"couch_httpd.erl"},{line,318}]},
{mochiweb_http,headers,5,
[{file,"mochiweb_http.erl"},{line,94}]},
{proc_lib,init_p_do_apply,3,
[{file,"proc_lib.erl"},{line,239}]}]
[Tue, 22 Nov 2016 13:45:10 GMT] [info] [<0.30579.229>] 127.0.0.1 - - PUT /DBNAME/external_link-35174841-41a5-44e3-a567-ec56209dc8b8-de_DE-1 409
[Tue, 22 Nov 2016 13:45:10 GMT] [debug] [<0.30579.229>] httpd 409 error response:
{"error":"conflict","reason":"Document update conflict."}
Any ideas what's going on here?
The docs say that conflicts can occur when several threads or programs try to update a document at the same time.
Are you sure you don't have another thread writing in your database, maybe a mapreduce? That would explain the different revision numbers.
Related
I have a server running LEMP stack that hosts a wide range websites. During the night, all the sites got shutdown and the message "502 bad gateway" Is displayed. I followed the stream of errors and concluded that php7.4-fpm was the issue. I need help to figure out how to solve the error below.
NOTE: During the night, no updates or changes has been made to the system
● php7.4-fpm.service - The PHP 7.4 FastCGI Process Manager
Loaded: loaded (/lib/systemd/system/php7.4-fpm.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Tue 2021-07-27 09:35:38 CEST; 7s ago
Docs: man:php-fpm7.4(8)
Process: 1561620 ExecStart=/usr/sbin/php-fpm7.4 --nodaemonize --fpm-config /etc/php/7.4/fpm/php-fpm.conf (code=exited, status=78)
Process: 1561621 ExecStopPost=/usr/lib/php/php-fpm-socket-helper remove /run/php/php-fpm.sock /etc/php/7.4/fpm/pool.d/www.conf 74 (code=exited, status=0/SUCCESS)
Main PID: 1561620 (code=exited, status=78)
Jul 27 09:35:38 Ubuntu-2010-groovy-64-minimal systemd[1]: Starting The PHP 7.4 FastCGI Process Manager...
Jul 27 09:35:38 Ubuntu-2010-groovy-64-minimal php-fpm7.4[1561620]: [27-Jul-2021 09:35:38] ERROR: [/etc/php/7.4/fpm/php-fpm.conf:98] value is NULL for a ZEND_INI_PARSER_ENTRY
Jul 27 09:35:38 Ubuntu-2010-groovy-64-minimal php-fpm7.4[1561620]: [27-Jul-2021 09:35:38] ERROR: failed to load configuration file '/etc/php/7.4/fpm/php-fpm.conf'
Jul 27 09:35:38 Ubuntu-2010-groovy-64-minimal php-fpm7.4[1561620]: [27-Jul-2021 09:35:38] ERROR: FPM initialization failed
Jul 27 09:35:38 Ubuntu-2010-groovy-64-minimal systemd[1]: php7.4-fpm.service: Main process exited, code=exited, status=78/CONFIG
Jul 27 09:35:38 Ubuntu-2010-groovy-64-minimal systemd[1]: php7.4-fpm.service: Failed with result 'exit-code'.
Jul 27 09:35:38 Ubuntu-2010-groovy-64-minimal systemd[1]: Failed to start The PHP 7.4 FastCGI Process Manager.
I'm grateful for any ideas that you could have!
Just an idea, as I had the same error today setting up a fresh Alma linux server with httpd and php74-php-fpm from the remi repository.
I suggest the root cause of your problem was that the config had been altered some time before your shutdown, and that bad config then lurked causing no immediate problem. At the time of the problem your servers were restarted for some reason, maybe an overnight job run by someone else, a regular update of system packages leading to daemons being restarted, or a power failure. When they tried to start up again, they used the current config, which was by that time corrupt.
In my case I was editing the FPM config file /etc/opt/remi/php74/php-fpm.d/www.conf and accidentally used a # character for a comment, e.g. # My changes. On restarting the server, I got the same value is NULL for a ZEND_INI_PARSER_ENTRY error message in the journal. The line numbers mentioned did not help, they basically referred to how php-fpm.conf includes every file in php-fpm.d which happens to include www.conf but didn't specify which line had the error.
The fix in my case was to use the correct ; (semicolon) character, and not a #, for comments in www.conf.
This may not have been your case but I hope it helps someone :)
Update: I solved this issue by removing php7.4-fpm and installing it again. However, the problem still remains. Why did php7.4-fpm suddenly stopped working?
I am using Laravel 5.4 version to implement mongodb CRUD operation using link. I am using Mac OS El Captain 10.11. I have installed mongodb.so extension with php version 7.1.16
While i am trying getting eloquent connection it throws me ERR_EMPTY_RESPONSE
I have digg in details an found following error log in Apache during restart the MAMP server
Mon Aug 28 10:22:14 2017] [notice] Graceful restart requested, doing restart
[Mon Aug 28 10:22:15 2017] [notice] Digest: generating secret for digest authentication ...
[Mon Aug 28 10:22:15 2017] [notice] Digest: done
[Mon Aug 28 10:22:15 2017] [notice] Apache/2.2.31 (Unix) mod_wsgi/3.5
Python/2.7.13 PHP/7.1.1 mod_ssl/2.2.31 OpenSSL/1.0.2j DAV/2
mod_fastcgi/2.4.6 mod_perl/2.0.9 Perl/v5.24.0 configured -- resuming normal operations
[Mon Aug 28 10:22:15 2017] [notice] FastCGI: process manager initialized (pid 4233)
dyld: lazy symbol binding failed: Symbol not found: _clock_gettime
Referenced from:
/Applications/MAMP/bin/php/php7.1.1/lib/php/extensions/no-debug-non-zts-20160303/mongodb.so
Expected in: /usr/lib/libSystem.B.dylib
dyld: Symbol not found: _clock_gettime
Referenced from:
/Applications/MAMP/bin/php/php7.1.1/lib/php/extensions/no-debug-non-zts-20160303/mongodb.so
Expected in: /usr/lib/libSystem.B.dylib
dyld: lazy symbol binding failed: Symbol not found: _clock_gettime
Referenced from:
/Applications/MAMP/bin/php/php7.1.1/lib/php/extensions/no-debug-non-zts-20160303/mongodb.so
Expected in: /usr/lib/libSystem.B.dylib
dyld: Symbol not found: _clock_gettime
Referenced from:
/Applications/MAMP/bin/php/php7.1.1/lib/php/extensions/no-debug-non-zts-20160303/mongodb.so
Expected in: /usr/lib/libSystem.B.dylib
This screenshot shows the details of mongodb extension
I have searched online for error dyld: lazy symbol binding failed: Symbol not found: _clock_gettime and found this answer. I have applied all steps which i mentioned, but unable to fix the issue.
Please someone help me to get rid of this.
First of you need to update your os to macOS Sierra, (I am using version 10.12)
clock_gettime was not provided in El Capitain,
Apple has (finally) introduced the clock_gettime posix API in Sierra. Our configure script detects this and enable usage of it. Since the binary isn't executed on Sierra, but instead on El Capitain where this functionality doesn't exist, the linking in runtime fails. Using the workaround you suggest is not a good solution. This might seemingly work, but it is not impossible that you get strange failures at a later time since the binary isn't compiled for the system it is executing on.
Reference From : https://bugs.erlang.org/browse/ERL-256
Latest versions of php{XX}-mongodb installed from homebrew rely on the use of a OS X 10.12 specific Symbol called _clock_gettime, which did not exists in OS X < 10.12.
Upgrading your system will solve this problem, but you might have some valid reasons to not wish to upgrade it.
There is a pull-request currently being Work-In-Progress to preserve the OS X 10.11 compatibility :
https://github.com/Homebrew/homebrew-php/issues/3737
https://github.com/Homebrew/homebrew-php/pull/3890
While this is not accepted, you can hack the phpXX-mongodb formula yourself, as nicely suggested by #adocwang here :
(Be sure to install xcode-select tools first)
sudo xcode-select --install
# Or if you already installed it
softwareinstall --install -a
Then edit the php{XX}-mongodb formula (that'll be php71-mongogb, php56-mongodb, or whatever PHP version you're using)
brew edit php{XX}-mongodb
Find the line of "def install", and replace
def install
Dir.chdir "mongodb-#{version}" unless build.head?
By
def install
Dir.chdir "mongodb-#{version}" unless build.head?
if MacOS.version == "10.11" && MacOS::Xcode.installed? && MacOS::Xcode.version >= "8.0"
inreplace %w[src/libbson/src/bson/bson-clock.c], "HAVE_CLOCK_GETTIME", "UNDEFINED_GIBBERISH"`
end
Then force the reinstallation of this formula from source
brew reinstall -s php{XX}-mongodb
Our application runs in a Docker container on AWS:
Operating system: Ubuntu 14.04.2 LTS (Trusty Tahr)
Nginx version: nginx/1.4.6 (Ubuntu)
Memcached version: memcached 1.4.14
PHP version: PHP 5.5.9-1ubuntu4.11 (cli) (built: Jul 2 2015 15:23:08)
System Memory: 7.5 GB
We get blank pages and a 404 Error less frequently. While checking the logs, I found that the php-child process is killed and it seems that memory is mostly used by memcache and php-fpm process and very low free memory.
memcache is configured to use 2 GB memory.
Here is php www.conf
pm = dynamic
pm.max_children = 30
pm.start_servers = 9
pm.min_spare_servers = 4
pm.max_spare_servers = 14
rlimit_files = 131072
rlimit_core = unlimited
Error logs
/var/log/nginx/php5-fpm.log
[29-Jul-2015 14:37:09] WARNING: [pool www] child 259 exited on signal 11 (SIGSEGV - core dumped) after 1339.412219 seconds from start
/var/log/nginx/error.log
2015/07/29 14:37:09 [error] 141#0: *2810 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: x.x.x.x, server: _, request: "GET /suggestions/business?q=Selectfrom HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "example.com", referrer: "http://example.com/"
/var/log/nginx/php5-fpm.log
[29-Jul-2015 14:37:09] NOTICE: [pool www] child 375 started
/var/log/nginx/php5-fpm.log:[29-Jul-2015 14:37:56] WARNING: [pool www] child 290 exited on signal 11 (SIGSEGV - core dumped) after 1078.606356 seconds from start
Coredump
Core was generated by php-fpm: pool www.Program terminated with signal SIGSEGV, Segmentation fault.#0 0x00007f41ccaea13a in memcached_io_readline(memcached_server_st*, char*, unsigned long, unsigned long&) () from /usr/lib/x86_64-linux-gnu/libmemcached.so.10
dmesg
[Wed Jul 29 14:26:15 2015] php5-fpm[12193]: segfault at 7f41c9e8e2da ip 00007f41ccaea13a sp 00007ffcc5730ce0 error 4 in libmemcached.so.10.0.0[7f41ccad2000+32000]
[Wed Jul 29 14:28:26 2015] php5-fpm[12211]: segfault at 7f41c966b2da ip 00007f41ccaea13a sp 00007ffcc5730ce0 error 4 in libmemcached.so.10.0.0[7f41ccad2000+32000]
[Wed Jul 29 14:29:16 2015] php5-fpm[12371]: segfault at 7f41c9e972da ip 00007f41ccaea13a sp 00007ffcc5730b70 error 4 in libmemcached.so.10.0.0[7f41ccad2000+32000]
[Wed Jul 29 14:35:36 2015] php5-fpm[12469]: segfault at 7f41c96961e9 ip 00007f41ccaea13a sp 00007ffcc5730ce0 error 4 in libmemcached.so.10.0.0[7f41ccad2000+32000]
[Wed Jul 29 14:35:43 2015] php5-fpm[12142]: segfault at 7f41c9e6c2bd ip 00007f41ccaea13a sp 00007ffcc5730b70 error 4 in libmemcached.so.10.0.0[7f41ccad2000+32000]
[Wed Jul 29 14:37:07 2015] php5-fpm[11917]: segfault at 7f41c9dd22bd ip 00007f41ccaea13a sp 00007ffcc5730ce0 error 4 in libmemcached.so.10.0.0[7f41ccad2000+32000]
[Wed Jul 29 14:37:54 2015] php5-fpm[12083]: segfault at 7f41c9db72bd ip 00007f41ccaea13a sp 00007ffcc5730ce0 error 4 in libmemcached.so.10.0.0[7f41ccad2000+32000]
While googling for this same issue, and trying hard to find a solution that was not related to sessions (because I have ruled that out) nor to bad PHP code (because I have several websites running precisely the same version of WordPress, and none have issues... except for one), I came upon an answer telling that a possible solution did involve removing some buggy extension (usually memcache/d, but could be something else).
Since I had this same site working flawlessly on one Ubuntu server, when switching to a newer server, I immediately suspected that it was the migration from PHP 5.5 to 7 that caused the problem. It was just strange because no other website was affected. Then I remembered that another thing was different on this new server: I had also installed New Relic. This is both an extension and a small server that runs in the background and sends a lot of analytics data to New Relic for processing. Allegedly, it's a PHP 5 extension, but, surprisingly, it loads well on PHP 7, too.
Now here comes the tricky bit. At some point, I had installed W3 Total Cache for the WordPress installation of that particular website. Subsequently, I saw that the performance of that server was so stellar that W3TC was unnecessary, and simply stuck to a much simpler configuration. So I could uninstall W3TC. That's all very nice, but... I forgot that I had turned New Relic on W3TC, too (allegedly, it adds some extra analytics data to be sent to New Relic). When uninstalling W3TC, probably there was 'something' left on the New Relic configuration in my server which was still attempting to send data through the W3TC interface (assuming that W3TC has an interface... I really have no idea how it works at that level), and, because that specific bit of code was missing, the php_fpm handler for that website would fail... some of the time. Not all the time, because I'm assuming that, in most cases, nginx was sending static pages back. Or maybe php_fpm, set to 'recycle' after 100 calls or so, would crash-on-stop. Whatever exactly was happening, it was definitely related to New Relic — as soon as I removed the New Relic extension from PHP, that website went back to working normally.
Because this is such a specific scenario, I'm just writing this as an answer, in the remote chance that someone in the future googles for the exact problem.
In my case it was related to zend debug/xdebug. It forwards some TCP packets to the IDE (PhpStorm), that was not listening on this port (debugging was off). The solution is to either disable these extensions or enable debug listening on the debugging port.
I had this problem after installing xdebug, adding some properties to /etc/php/7.1/fpm/php.ini and restarting nginx. This is running on a Homestead Laravel box.
Simply restarting the php7.1-fpm service solved it for me.
It can happen if PHP is unable to write the session information to a file. By default it is /var/lib/php/session. You can change it by using configuration session_save_path.
phpMyAdmin having problems on nginx and php-fpm on RHEL 6
In my case it was Xdebug. After uninstalling it, it got back to normal.
In my case, it was caused by the New Relic PHP Agent. Therefore, for a specific function that caused a crash, I added this code to disable New Relic:
if (function_exists('newrelic_ignore_transaction')) {
newrelic_ignore_transaction();
}
Refer to: https://discuss.newrelic.com/t/how-to-disable-a-specific-transaction-in-php-agent/42384/2
In our case it was caused by Guzzle + New Relic. In the New Relic Agent changelog they've mentioned that in version 7.3 there was some Guzzle fix, but even using the 8.0 didn't work, so there is still something wrong. In our case this was happening only in two of our scripts that were using Guzzle. We found that there are two solutions:
Set newrelic.guzzle.enabled = false in newrelic.ini. You will lose data in the External Services tab this way, but you might not need it anyway.
Downgrade New Relic Agent to version 6.x that somehow also works
If you are reading this when they've released something newer than version 8.0, you could also try to update New Relic Agent to the latest and maybe they fixed that
In my case I had deactivated the buffering function ob_start("buffer"); in my code ;)
A possible problem is PHP 7.3 + Xdebug. Please change Xdebug 2.7.0beta1 to Xdebug 2.7.0rc1 or the latest version of Xdebug.
For some reason, when I remove profile from my xdebug.ini modes, it fixes it for me.
i.e. change
xdebug.mode=debug,develop,profile
to
xdebug.mode=debug,develop
I am using symlinks to share the Wordpress core directory. It is working in my local machine, but when I try to deploy it on my Plesk server owned by Rackspace I have some right issues because the shared folder can't have two allowed user to access it via PHP. Indeed I have the following error:
[Thu Jul 09 10:08:53 2015] [error] [client 74.125.45.136] PHP Warning: require() [<a href='function.require'>function.require</a>]: SAFE MODE Restriction in effect. The script whose uid is 10001 is not allowed to access /var/www/vhosts/mysite2.com/blog/wordpress/wp-blog-header.php owned by uid 10004 in /var/www/vhosts/mysite2/blog/index.php on line 17, referer: http://www.mysite2.com/blog/
I do not have this error with mysite1.com/blog because the user owning the wordpress folder is mysite1ftp such as:
drwxrwsr-x 69 mysite1ftp group 4096 Jul 9 09:12 mysite1.com
drwxrwsr-x 44 mysite2ftp group 4096 Jul 8 16:53 mysite2.com
drwxrwsr-x 5 mysite1ftp group 4096 Jul 2 11:15 wordpress
Do you think there is any solution to do that? How can the wordpress folder be accessible by both mysite1ftp and mysite2ftp?
The problem you're encountering is that Rackspace has enabled Safe Mode. This is an archaic and fairly ineffective means of securing PHP installations. If you control the configuration of the Plesk server, the “best” solution would be to switch to PHP-FPM, or at least mod-ruid2. Without disabling Safe Mode, the PHP interpreter will not evaluate scripts owned by different users in the same request, which inherently at odds with what you're trying to accomplish.
Assuming all the installs are on the same instance and thus can have the same files shared between them, then the main thing you need to do is to have all the custom content stuff live outside of the main WordPress folders.
check,
http://wordpress.stackexchange.com/questions/57109/how-to-share-wordpress-core-library
When I try to run mvn sonar:sonar -e in projects root dir build is falling with error:
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Can not execute Sonar
Embedded error: Unable to read and import the source file : '/www/hudson/proj_beta/source/bin/report.php' with the charset : 'UTF-8'.
org.sonar.api.resources.File#10ade81[key=bin/report.php,dir=bin,filename=report.php,language=PHP]
[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Can not execute Sonar
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Can not execute Sonar
at org.codehaus.mojo.sonar.Bootstraper.executeMojo(Bootstraper.java:103)
at org.codehaus.mojo.sonar.Bootstraper.start(Bootstraper.java:79)
at org.codehaus.mojo.sonar.SonarMojo.execute(SonarMojo.java:88)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
Caused by: org.sonar.api.utils.SonarException: Unable to read and import the source file : '/www/hudson/c2c_beta/source/bin/report.php' with the charset : 'UTF-8'.
at org.sonar.api.batch.AbstractSourceImporter.parseDirs(AbstractSourceImporter.java:84)
at org.sonar.api.batch.AbstractSourceImporter.analyse(AbstractSourceImporter.java:69)
at org.sonar.api.batch.AbstractSourceImporter.analyse(AbstractSourceImporter.java:60)
at org.sonar.batch.phases.SensorsExecutor.execute(SensorsExecutor.java:64)
at org.sonar.batch.phases.Phases.execute(Phases.java:93)
at org.sonar.batch.bootstrap.ProjectModule.doStart(ProjectModule.java:143)
at org.sonar.batch.bootstrap.Module.start(Module.java:83)
at org.sonar.batch.bootstrap.BatchModule.analyze(BatchModule.java:111)
at org.sonar.batch.bootstrap.BatchModule.doStart(BatchModule.java:101)
at org.sonar.batch.bootstrap.Module.start(Module.java:83)
at org.sonar.batch.bootstrap.BootstrapModule.doStart(BootstrapModule.java:102)
at org.sonar.batch.bootstrap.Module.start(Module.java:83)
at org.sonar.batch.Batch.execute(Batch.java:100)
at org.sonar.maven.SonarMojo.executeBatch(SonarMojo.java:152)
at org.sonar.maven.SonarMojo.execute(SonarMojo.java:142)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at org.codehaus.mojo.sonar.Bootstraper.executeMojo(Bootstraper.java:98)
... 21 more
Caused by: org.sonar.api.resources.DuplicatedSourceException: org.sonar.api.resources.File#10ade81[key=bin/report.php,dir=bin,filename=report.php,language=PHP]
at org.sonar.batch.index.SourcePersister.saveSource(SourcePersister.java:45)
at org.sonar.batch.index.DefaultPersistenceManager.setSource(DefaultPersistenceManager.java:78)
at org.sonar.batch.index.DefaultIndex.setSource(DefaultIndex.java:402)
at org.sonar.batch.DefaultSensorContext.saveSource(DefaultSensorContext.java:159)
at org.sonar.api.batch.AbstractSourceImporter.parseDirs(AbstractSourceImporter.java:81)
... 37 more
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2 minutes 23 seconds
[INFO] Finished at: Wed Feb 08 14:50:49 EET 2012
[INFO] Final Memory: 16M/42M
[INFO] ------------------------------------------------------------------------
It started to fall after unit-test were added to source dir.
Google search didn't give any clue.
The file is in utf-8:
report.php: text/plain; charset=utf-8
Any suggestions?
Looks like an open issue with Sonar, caused due to the same php file name in say, source and test folders. The issue exists for java as well. According to this, this should be fixed in the next release.
Possible Workaround:
If you encounter this problem, you can try to rename (if possible)
the test files that make the analysis fail
First, are all your sources encoded in UTF-8?
If so, have you tried removing the report.php source file, just to see if it's not only this class that has a problem?