-
-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Serenata crash after upgrade to v5 #483
Comments
Glad to hear you enjoyed it and sorry to hear that you're having problems now 😃 . Thanks for trying to help debug this by posting logs. I do see in the logs that the socket is being closed unexpectedly. It is possible that Serenata is indeed crashing. If I understood correctly, Serenata is working for you correctly for the smaller project? If this is the case, then the problem for the larger project may be related to memory issues, though the default is already around 2GB, which is large (though I don't know how large your large is, of course). You can try upping it in the settings just to see if that is indeed the problem. Apart from that, are you using Docker to run or just an ordinary PHP executable? I'm asking because Docker on macOS has its own, separate memory limit. Finally, when this happens, could you take a look in the developer tools to see if under "All Levels" the "Verbose" setting is also enabled? There may be log messages from Serenata that are being hidden by default. I also see this: |
I doubled the mem to 4G with the same result. The project directory is ~1.5G but >1G of that is non-php dependencies -- mostly
The php executable on my mac:
... and for good measure:
I enabled the verbose option. Here's the log with that enabled:
|
@lcharette gave me an idea. Could you try executing the following: php ~/Library/Preferences/php-ide-serenata/distribution.phar --uri=127.0.0.1:12345 ... and post the output? (I'm not entirely sure that is the right folder on macOS, so you may need to update it.) It is possible I accidentally made the code incompatible with PHP < 7.3, e.g. by writing a trailing comma somewhere. Serenata has tests running on each PHP version individually, but there are some files, such as Running Serenata manually should immediately trigger the error, if there is any, I hope. |
No prob. It hangs here indefinitely: $ php ~/Library/Preferences/php-ide-serenata/distribution.phar --uri=127.0.0.1:12345 -vvv
Starting server bound to socket on URI 127.0.0.1:12345... |
Hmm, that seems to be the expected behavior. So the server is not crashing immediately on startup, but the socket is immediately closing when it's started in Atom, though there is no strange output of any kind. In fact, I saw the same "Starting server..." message in your logs, the socket just closes sometime later. Do you perhaps have some kind of firewall active that blocks arbitrary ports being opened? |
No. Note that at least one other project I've tested in my env does not exhibit the behavior. |
Right, good of you to mention that, as I already forgot - dealing with too many tickets simultaneously, probably. Do you have system logs of any kind that may have logged issues? It can always be e.g. a SIGSEGV that doesn't print any output. If there are problems with the database or Serenata of any kind, you should always be seeing some sort of logging in Atom, so this is sounding more and more like an external factor or a severe issue (i.e. SIGSEGV) that is preventing output from being displayed. |
This log seems to point to the problem since a similar entry coincides with each crash.
|
I did some lookup, but there doesn't appear to be a lot of information about AMFI. I did find that it supposedly refers to AppleMobileFileIntegrity and that this apparently also exists in macOS itself. It may be coincidence in the sense that it is indeed disallowing the exception handler, but is only blocking it because the process crashed already, and not causing the crash itself. Could you take a look if a database for the project that is crashing is generated in the php-ide-serenata cache folder (same one where the PHAR from before is located) and see if there are some items in the File table or some tables have data present? In case you're feeling adventurous, There have been users in the past experiencing problems where some files in the php-ide-serenata cache folder were read-only. You mentioned that Serenata crashes almost immediately "when indexing begins". This makes me wonder if there is something special along the lines of files (symlinks, files without read permissions, and so on), and so on, but I can't think of any of these that wouldn't generate some kind of error. For example, if Serenata cannot process a file due to it thinking that it contains syntax errors, a big fat error should show up in the developer tools. EDIT: Another avenue is to clone latest Serenata git, run |
I finally pinned this down and have a workaround in place in my env. I'm fairly certain you'll be able to replicate by installing |
I'm having the same problem, but your solution didn't help.
And them the same error 8 or 10 times:
And finally:
There was also an error on ide-vue package, but I uninstalled that and it seems not related. |
FYI I've downgraded to 4.5.3 and it's working now (I had to set up more memory as I had a new crash due to the 2Gb limit). |
@marcguyer Good to hear you were able to pinpoint the issue. I tried installing Faker in a test project, but the file seems to index just fine here. I even get code lenses in that file. You are always welcome at the Serenata issue tracker if you have questions, have time and want to help track the issue down. It is possible that there is an indirect issue, perhaps indeed a character set issue (source code is converted to UTF-8 in Serenata before analysis), some PHP extension that has a specific setting causing problems with indexing, strange behavior of a native library during conversion of text, and so on. @underdpt If you are also experiencing some projects that are working fine and others that aren't, you can try following the same process and answering the same questions as @marcguyer did above, perhaps there is also a specific file that is generating problems. |
HI @Gert-dev This happens in Windows OS, FYI. Anything I can do to debug this? |
Yes, I'm using xdebug. Disabled Xdebug on the php version i'm using for Atom, updated to 5.0.2 and it's working, thanks! |
Thanks for letting me know. The issue should now be fixed (see also #484). |
I just realized the original issue with some files not being indexed likely wasn't fixed. This is however probably an issue in Serenata itself, so anyone is free to open an issue in Serenata's issue tracker for it (preferably with some sort of test case that I can reproduce as well 😄). |
I'm getting the same error message as @marcguyer:
I tried php ~/.cache/php-ide-serenata/distribution.phar --uri=127.0.0.1:12345 ...and got:
So I removed Now, when reindexing the project in Atom, I'm getting this several thousand times in the console:
And the indexing runs endlessly... |
I, too, have had a similar experience since the latest version last week. Prior to that update, everything was working well in my env. Previously my workaround was to remove a giant php file in an app dependency. I'm still not sure why Serenata chokes on that file... The current problem appears to be different and should likely have it's own ticket -- Also, I don't know but I suspect the Serenata server rather than this Atom plugin as the source of the issue. Below is an example of the 1000's of entries I see in the Atom console. There seems to be an entry for each php file in my project.
I suppose it could be that I have a "corrupted" index at this point so I'll reset everything again and see what I get in the console. |
I tried this again on 2 different projects after resetting everything (delete phar and index dbs, ensure no zombie php processes, restart Atom). Both projects indexed completely. Aside, it appears that the primary difference in the latest minor version of the server (5.1.0) is that the phar itself is indexed and included into the same index as the project. @Gert-dev wouldn't it be more efficient to have a dedicated index for the phar? Just asking... I suppose there are likely some technological limitations there... Both projects are happy right now but I've fallen for that ruse before... Based on recent experience, I expect to start seeing errors in the console after coding for a bit. I'll keep an eye on it and report back here either way. |
So far, no errors after reinitializing... I think both the error I reported last and what @ThomasLandauer is experiencing is reported in the the server here: https://gitlab.com/Serenata/Serenata/issues/307. However, contrary to that issue report description, it's not just annoying messages, but also that the server eventually fails due to repeated crashes. |
Thanks to @marcguyer the following steps fixed it for me (at least for the moment):
Result: Indexing ran through just fine :-) |
Thanks for letting me know. I've added some documentation to the wiki about possible extensions you can use for the Event Loop. There wasn't any documentation about this previously, so it was hard for anyone to know the server is even using it. For the SQLite database, users have been reporting corruptions as long as I can remember (I haven't experienced them myself, though). Possibly it is related to varying combinations of hardware and software, which are rather hard to debug. In Finally, you are right, this package doesn't do any indexing itself, most issues, barring cosmetic ones and ones related to integration, are happening in the server or Serenata itself. |
To be clear, I'm using "corruption" as a generic term. Whenever I run into these issues, I brute-force reset everything to a known state to avoid my unknowns and get a clean run from scratch. I'm not sure I can say that true db corruption has ever been experienced. I've only suspected that the db is in an unexpected state at times... Specifically, when I see hundreds of "Could not find file xxx in index" I must assume that the file is expected to be in the index. I understand that IRL you could have a situation where a file is expected to not exist in the index -- copy/paste, etc -- but these are all files that I expect were already previously indexed, making the error a surprise. |
Hi everyone ! Great work indeed with serenata ! I'm loving it daily ! I just wan't to describe what I figured out, experiencing the same issues with infinite loop of exceptions leading to serenata crashes and not finding files into the index. I thought maybe that my project / my IDE were in an conflicting state so I investigated. I saw that my serenata was up to date, but not my atom. So I erased my .serenata folder, upgrade and restart my atom. It was still not working. Then I uninstall my serenata package, reload my window, reinstall serenata... It works like a charm now. Not a single exception right now. Hope it will help, Cheers |
I've enjoyed using Serenata in Atom for quite some time but since upgrade to v5, the server crashes almost immediately when indexing begins in my project. The console is littered with errors that don't seem to make much sense (to me anyway). Eventually this error pops up:
I've tried completely purging Serenata and related atom config from my system, then reinstalling the
php-ide-serenata
package in Atom but I get the same behavior.I have a fairly large project where I'm seeing this behavior. I tried a smaller project and it doesn't seem to exhibit this issue. Unfortunately, I can't seem to find any indication of why one would crash the server while another doesn't. Here's an export of the console log from Atom:
serenata_console.log.zip
The text was updated successfully, but these errors were encountered: