As stated by this solution, the workaround proposed works very well on dev and test SS environments.
The suggested one is to avoid the current bug related to auto-publish files managed via DataObject $owns property.
But since I uploaded my project in production - on live env - the workaround doesn't work anymore.
In my case I'm working on a DataExtension of User model. The rest of implementation follows exactly the above mentioned case - with UploadField.
In production, it seems that the snippet is ignored in its condition. In particular, this is my version:
UserExtension
// AllegatiDownload: many_many File type uploaded with UploadField
public function onAfterWrite()
{
if ($this->owner->AllegatiDownloadID) { // <- This is being ignored in live version
$this->owner->AllegatiDownload()->publishSingle();
}
parent::onAfterWrite();
}
If I try to replace
$this->owner->AllegatiDownloadID
with
$this->owner->AllegatiDownload()
The condition pass, but $this->owner->AllegatiDownload()->publishSingle() returns an untraced 500 exception. Just:
There was been an error
And, as I said, this happens only in production.
Thanks in advance for support.
Today I flushed the project DB in order to upgrade a custom front-end component that interacts with it. Seems that after that flush, the issue being solved. That's pretty strange, because I tried many /dev/build?flush=all before, and nothing happened. Server cache maybe? I don't know. But now the workaround works as expected.
Thanks anyway for the support.
hope you're good
I was trying to add a profile table to my Laravel 5.6 project, and I'm also using the spatie\Laravel-Permission package. It was working fine, but after I ran some migrations (that have nothing to do with users), it started failing on the login. The curious thing is that, if I register a new user, it gets logged in properly, but never with the /login route (I'm using the Laravel's Auth scaffolding).
After debugging the project, I came up with the method that's failing, it's something reading the sessions:
MyProject\vendor\laravel\framework\src\Illuminate\Filesystem\Filesystem.php
<?php
namespace Illuminate\Filesystem;
use ErrorException;
use FilesystemIterator;
use Symfony\Component\Finder\Finder;
use Illuminate\Support\Traits\Macroable;
use Illuminate\Contracts\Filesystem\FileNotFoundException;
class Filesystem{
// ...
public function get($path, $lock = false)
{
if ($this->isFile($path)) {
return $lock ? $this->sharedGet($path) : file_get_contents($path); // <-- The failing line
}
throw new FileNotFoundException("File does not exist at path {$path}");
}
// ...
}
Once it gets to that line, the debugger stops, the browser doesnt get a response, the dd() function does not get triggered... I also tried to debug the sharedGet($path) method, and it returns the value, but back to the method above, it stops.
Also, the php_error.log file gets absurdly increased on every request (up to 500MB/request), so much that none of the editors I use can open it (SublimeText, NetBeans).
My thoughts are that apache may be running out of memory when reading the files, but the session file barely weights 1k, so it wouldn't make much sense.
Can someone throw any clue? Thanks
--EDIT:
I tried installing a fresh laravel proyect with only the Auth module and the spatie/laravel-permission package, and I noticed the same behaviour: it registers and logs users, but after logging it out, I'm no longer able to log in with any user.
In case someonw gets to the same error:
I could manage to solve this by backing up all my projects/databases and reinstalling wampserver with the last version of php (by the moment of this answer, it is 7.2.4) and reinstalling Laravel (luckily the proyect was barely starting), which only updated vlucas/phpdotenv package from 2.4.0 to 2.5.0 and phpunittest.
Whith this update now I can log in users normally, now let's see if it works as it should with spatie/laravel-permission package and the profile table I need to add.
I just pushed a Laravel website onto a shared hosting. Copied the public folder to the /www, changed the index.php to reflect the path change and configured my .htaccess, etc.
At first I was simply getting an error, telling me that Page::findBySlug() returned null. Checked again with dd(), was and still is null.
FrontendController#index is looking like this
public function index($slug)
{
$page = Page::findBySlug($slug);
$pageTemplate = $page->templates->first();
return view('frontend.pages.index', compact('page','pageTemplate'));
}
and after toying with dd() for a while, it now sends me to the custom 500 unless it's supposed to pull the slug from db, in which case I get a custom 404.
EDIT: I pulled the same version of the app but with it being already installed (instead of rolling with composer instal) from the testing platform and it simply works so I doubt it has anything to do with the hosting. I'd still appreciate an answer given that I'd like to do it the correct way. Is there anything I should setup slugs-wise after running a fresh install?
What am I missing here? Thanks.
Try $page= Page::where('slug',$slug)->first();
Try to update your php veersion to 7.0 .
Fixed by php artisan route:clear.
Apparently route:cache wasn't the way to go.
I'm trying to use the template from http://jenkins-php.org in my installation of Jenkins. As soon as I go in to configure the project I get a grey screen appearing and the words 'Loading'
If I look in the Browser error console I get TypeError: 'undefined' is not an object (evaluating 'registry.get')
Has anyone else experienced this problem? How can this be fixed?
We had this problem when upgraded to 1.528.
Digging further, we found out that the problem is originated from one of the client-side script files called "hudson-behavior.js" and is caused by the "Publish Over SSH" plugin. There have been other plugins that have caused this in the past, as well. We couldn't disable the plugin anyway. So we searched further.
Long story short, we ended up changing the script for the time being. If you, like us, install Jenkins using the war file, then the script file is probably extracted and cached in "/var/cache/jenkins/war/scripts/hudson-behavior.js".
The following change we made was in a function called "registerValidator":
if (depends==null) { // legacy behaviour where checkUrl is a JavaScript
try {
return eval(url); // need access to 'this', so no 'geval'
} catch (e) {
// set depends to an empty array.
depends = [];
}
}
var q = qs(this).addThis();
The URL may not always be valid. Thus, a try-catch is in order. Hope this helps!
I've just had the same issue, I'm using version 1.523 of Jenkins on an Ubuntu server.
The solution I found was to manually edit the project config.xml file.
sudo vim /var/lib/jenkins/jobs/yourProjectName/config.xml
I had images in the description and I removed those leaving the description tag empty.
I also had an empty plot section which I removed completely from the publishers section.
After saving the config and going back to 'manage Jenkins' and then 'Reload Configuration from Disk' I then reopend my project and the config opened normally again.
I wasn't getting quite the same error message as you in the browser console to start with, but I hope that helps.
I too downgraded to 1.523 and then it worked... So it's obviously some bug introduced after 1.524.
Upgrading from 1.530 to 1.531 fixed it for me.
When a PHPUnit test fails normally on my dev box (Linux Mint), it causes a "Segmentation Fault" on my Continous Integration box (Centos). Both machines are running the same version of PHPUnit. My dev box is running PHP 5.3.2-1ubuntu4.9, and the CI is PHP 5.2.17. I'd rather leave upgrading the PHP as a last resort though.
As per this thread: PHPUnit gets segmentation fault
I have tried deactivating / reinstalling Xdebug. I don't have inclue.so installed.
On the CI box I currently only have two extensions active: dom from php-xml (required for phpunit) and memcache (required by my framework), all the others have been turned off.
Next to what cweiske suggests, if upgrading PHP is not an option for you and you have problems to locate the source of the segfault, you can use a debugger to find out more.
You can launch gdb this way to debug a PHPUnit session:
gdb --args php /usr/bin/phpunit quiz_service_Test.php
Then type in r to run the program and/or set environment variables first.
set env MALLOC_CHECK_=3
r
You might also consider to install the debugging symbols for PHP on the system to get better results for debugging. gdb checks this on startup for you and leaves a notice how you can do so.
I've had an issue with PHPUnit segfaulting and had trouble finding an answer, so hopefully this helps someone with the same issue later.
PHPUnit was segfaulting, but only:
If there was an error (or more than one)
After all tests had run but before the errors were printed
After a while I realized that it was due to failures on tests that used data providers, and specifically for data providers that passed objects with lots of recursive references. A bell finally went off and I did some digging: the problem is that when you're using data providers and a test fails, PHPUnit tries to create a string representation of the provided arguments for the failure description to tell you what failed, but this is problematic when one of the arguments has some infinite recursion. In fact, what PHPUnit does in PHPUnit_Framework_TestCase::dataToString() (around line 1612) is print out all the arguments provided by the data provider using print_r, which causes the segfault when PHP tries to create a string representation of the infinitely recursive object.
The solution I came to was:
Use a single base class for all my test classes (which fortunately I was already doing)
Override dataToString() in my test base class, to check for these kinds of objects in the data array (which is possible in my case because I know what these objects look like). If the object is present, I return some special value, if not I just pass it along to the parent method.
I had similar problem and by disabling the garbge collactor in
PHPStorm => Edit configuration => Interpreter option : -d
zend.enable_gc=0
Or if you are running your tests from the command line you may try adding :
-d zend.enable_gc=0
When you get a segfault, upgrade your PHP to the latest version. Not only the latest in your package manager, but the latest available on php.net. If it still segfaults, you are sure that the problem has not been fixed yet in PHP itself. Don't bother trying to get rid of a segfault in old version of PHP because it might have been fixed already in a newer one.
Next step is to locating the problem: Make your test smaller and smaller until you can't remove anything (but it still segfaults). If you have that, move the test into a standalone php script that segfaults. Now you have a test script for your bug in the PHP bug tracker.
In addition to https://stackoverflow.com/a/38789046/246790 which helped me a lot:
You can use PHP function gc_disable();
I have placed it in my PHPUnit bootstrap code as well with ini_set('memory_limit', -1);
I had the same problem and could nail it down, that I tried to write a class variable which was not definied:
My class (it's a cakePHP-class) which caused segmentation fault:
class MyClass extends AppModel {
protected $classVariableOne;
public function __construct($id = false, $table = null, $ds = null) {
parent::__construct($id, $table, $ds);
$this->classVariableOne =& ClassRegistry::init('ClassVariableOne');
// This line caused the segmentation fault as the variable doesn't exists
$this->classVariableTwo =& ClassRegistry::init('ClassVariableTwo');
}
}
I fixed it by adding the second variable:
class MyClass extends AppModel {
protected $classVariableOne;
protected $classVariableTwo; // Added this line
public function __construct($id = false, $table = null, $ds = null) {
parent::__construct($id, $table, $ds);
$this->classVariableOne =& ClassRegistry::init('ClassVariableOne');
$this->classVariableTwo =& ClassRegistry::init('ClassVariableTwo');
}
}
Infinite recursion is normally what causes this issue for us. The symptoms of infinite recursion seem to be different when running code under phpunit, than they are when running it in other environments.
If anyone comes across this in relation to PHPunit within Laravel
It took a while to figure out what the issue was. I was going over the differences between my current code and the previous revision and through some trial and error finally got there.
I had two different models that were both including each other with the protected $with override.
This must have been causing some kind of loop that phpunit could not deal with.
Hopefully someone finds this useful.
Please update to the newest XDEBUG. Got the same error while using v3.1.5, and after upgrading to 3.1.6 eveything works.
I got into the same problem. I upgraded the PHPUnit to the 4.1 version (to run the tests) and it was able to show me the object, as pointed by Isaac.
So, if you get to this very same problem, upgrade to PHPUnit >= 4.1 and you'll be able to see the error instead of getting "Segmentation fault" message.
I kept getting a Segmentation fault: 11 when running PHPUnit with Code coverage. After doing a stack trace of the segmentation fault, I found the following was causing the Segmentation fault error:
Program received signal SIGSEGV, Segmentation fault.
0x0000000100b8421a in xdebug_path_info_get_path_for_level () from /usr/lib/php/extensions/no-debug-non-zts-20121212/xdebug.so
I replaced my current xdebug.so in the path above with the latest version from the Komodo Remote Debugging Package the sub-folder of the corresponding downloaded package with the PHP version I have (which is 5.5 for me) and everything worked.
The following fixed a similar issue for me (when the output of the gdb backtrace included libcurl.so and libcrypto.so):
disable /etc/php.d/pgsql.ini:
; Enable pgsql extension module
; extension=pgsql.so
edit /etc/php.d/curl.ini to ensure that pgsql.so is included before curl:
; Enable curl extension module
extension=pgsql.so
extension=curl.so
curl.cainfo=/home/statcounter/include/config/cacert.pem
if you have an object with property pointing to the same object, or other sort of pointer loops, you will have this message while running
serialize($object);
And if you are a Laravel user, and you are dealing with models. And if you think, you will never have this problem, because you avoiding pointer loops by using $hidden property on your models, please be advised, the $hidden property does not affect serialize, it only affects casting to JSON and array.
I had this problem, when I had a model saved into a property of a Mailable object.
fixed with
$this->model->refresh();
in a __construct method , just before the whole object is serialized.
This related to code not extension. In my case i had these two files
Test Case
Example Test
In Test Case there is method called createApplication. Just leave it empty.
In Example Test you can create the method and fill with
$this->assertTrue(true)
Above is basic setup hope you can extend the requirement as you need.