5.22.0 "Could not get storage class for SomeInterface" #10708
Comments
|
I found these snippets: https://psalm.dev/r/fe6bc2aace<?php
class Foo {
/**
* @global static $bar
* @return void
*/
public function instance() {
global $bar;
$bar->instance();
}
}https://psalm.dev/r/9aa415b204<?php
class Foo {
/**
* @global Wrong $bar
* @return void
*/
public function instance() {
global $bar;
$bar->instance();
}
} |
This probably means Psalm didn't really work correctly on your codebase before. The problem could manifest itself as a wrong type inference, appearing and disappearing depending on the number and order of files Psalm scanned during the check, for example. Now it's an outright crash, and this means we're one step closer to the actual fix.
I think Xdebug itself can work with multiple forked processes, according to the discussion in https://bugs.xdebug.org/view.php?id=1771. They also mention that some IDEs may limit the number of concurrent debug connections to, like, 1. |
|
Thanks @weirdan , I think you are right about the existing problem being the root cause. Debugging with Xdebug and PhpStorm does not work, PhpStorm keeps complaining about the "SERVER_NAME" not being defined in $_SERVER once in threaded mode (it works fine before forking, even though there is no "SERVER_NAME" configured then either...). So I've switched to dbgp which works fine, even with threading. Tip for anyone trying this: Once the process forks, it tries to setup a new debug connection in the background, but the first debugging process blocks the incoming request. So first do a So, I'm now able to step into the situation where Psalm crashes. The stacktrace reads: I can also see that the class requested is not present in the $storage array, so it makes sense that it throws there. However, I do not understand why it is not in that array. There are 33 classes in $storage, way less than I have in my codebase (but a lot of legacy files that probably contain numerous "errors"). The requested class exists, but probably is not processed but already referenced? I do not understand enough of the Psalm internals to fully understand this. Hope this helps you pointing the exact cause. If I need to do some more debugging I'm willing to help, just give me some pointers :) Thanks for your help so far. |
|
@florisluiten See line 4 of your output
Then this: |
|
Please try with |
|
@weirdan I can confirm that Psalm no longer crashes! 🎊 Also, the output doesn't throw any (new) warnings, so all is well. Thanks for your help! |
|
Fixed in 5.22.2 |
I'm having a related issue to #10706 , preventing me from updating to version 5.22.0. I've used the Changelog and discovered that when I revert the changes from https://github.com/vimeo/psalm/pull/10603/files#diff-90d3f6742878717c6bf051442dc8b3782579ea1b21bde8195cd47b3af03f456e the issue is gone.
My biggest problem is that Psalm crashes, giving me no clue about what file actually triggered the issue. This also makes it very hard to pin down the problem. Also, I use a baseline file that probably has the issue ignored, but the error occurs during the "parsing" phase, so I think that the baseline has no impact.
I've noticed that running it with the
--debugflag makes the issue disappear. I also noticed that the problem is only triggered in threaded mode (--threads=4). This also makes it very hard for me to debug the issue since a step-debugger doesn't seem to work in threaded mode; and when ran with--threads=1the step-debugger works but the issue is not triggered. This makes a simple STR very hard.I think that there are two problems:
The second problem can be reproduced with https://psalm.dev/r/fe6bc2aace ; As seen, Psalm crashes and gives no useful feedback. However, with https://psalm.dev/r/9aa415b204 the crash does not occur and the user can actually see the problem, which is way more helpful.
TLDR: Psalm crashes with "Could not get storage class for SomeInterface", and on a large codebase with a baseline file I find it impossible to find the cause of the problem and this prevents me from updating to 5.22.0.
The text was updated successfully, but these errors were encountered: