-
-
Notifications
You must be signed in to change notification settings - Fork 933
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
Sonic PI Crashing on start for users 4.1.0 #3207
Comments
Hi @acoopermp, so sorry you're having an issue. I'll try my best to get things working for you - it's really important to me that it works well for schools. Could I ask which version you were using prior to 4.1 and whether that was working fine on the same machines? Also, it would be really useful to get a full listing of all the logs found in ~/.sonic-pi/log (where ~ represents the users home directory). One option is that somehow Sonic Pi can't figure out where the user's home directory is. Usually this is fine, but I have been aware on some Windows cluster setups it needs a bit of a helping hand. Could you try setting the environment variable |
Hi @samaaron Previously we were using 3.2.2 and as far as I am aware, there were no issues with that version.
During a little bit of testing this morning after your message last night, I've set the I can send over the logs files too if you like, but not sure hows best to send the folder over. Apologies, a critical error occurred during startup: Please consider reporting a bug at Sonic Pi Boot Error ReportSystem InformationSonic Pi version: 4.1.0 Logs: spider.log: ===========
|
OK, great - so it looks like part of the problem was figuring out where the user's home drive was. Setting The other issue looks to be a network problem. Sonic Pi uses multiple processes which need to talk to each other on the local loop back network (they don't need to talk to other machines or the internet). Sometimes firewall settings can get in the way of this - perhaps this is the issue here? Could you check that Erlang (the system Sonic Pi uses for its IO) has permission for private network access in your Firewall settings? |
Windows firewall is actually disabled on computers as Sophos overrides this. However, I'm not getting any events or detections of it blocking this. When looking at the windows firewall list Erlang doesn't appear in it at all. In addition, I've just completely disabled Sophos on a machine and it's the same error. |
OK, that's definitely the problem then. Somehow the Erlang process isn't starting. Would it be possible to do a quick sanity check? Could you open a terminal, It should print:
|
Also, could you confirm that |
There might be an issue in that I can't run CMD as a student, which is where the issue is. As an admin or staff, it works with no problem, so I would expect doing this to succeed when running to run the above command. I will adjust some GP settings and allow a 'student' user access to CMD and such, so we what this reveals. and yes, that path is correct. |
Oh interesting. Could you let me know more about how you disable CMD access? Would that preclude binaries from running |
BTW, this is all amazingly helpful - thank-you so much for your time working through this! |
It's not a problem happy to help, I'm surprised this hasn't cropped anywhere else, to be honest, I wonder what our school might be doing differently to cause these issues. CMD is blocked through group policy along with a ton of other windows bits they shouldn't have such as a lot of customisation settings. Managed to run the command and got the following output |
Also, forgot to answer, yes, it's probably stopping .BAT files from running. If this is the case, I'm not sure how it's working on some of the other computers. |
OK, seems like the Windows terminal I was using had a slightly different env which wasn't causing the Despite this difference, it appears that Erlang is at least able to execute and do stuff - which is all I was trying to ascertain. The hypothesis that your policy might stop .BAT files from being executed from running processes feels extremely likely to be the cause of this issue. It would explain why things were working for you in v3 as the boot process didn't use any .BAT files. It was only the introduction of v4 that brought them in. I think I should be able to circumnavigate this, but it will take quite a bit of work and require me to cut a new MSI. Still, as you say it doesn't explain why it works on some of your computers and not others. Perhaps that's just the |
Oh wait, I got my logic reversed. You're right it doesn't explain why it does work on some machines. That is very odd. Could it be that the policy hasn't been uniformly applied? |
I've luckily enough just had a conversation with 2 students who were the ones using it who had mentioned it worked and discovered they were still using the 3.2.2 version previously deployed, meaning the 4.1.0 version works for no one currently. I'm not sure what I can do to allow .BAT files temporarily in order for it to work, but I'd imagine it's a pretty similar approach across schools if I'm honest blocking access to CMD entirely to stop them from accessing things they shouldn't, but I might ask around on some school forums to see if anyone does anything differently. |
Oh, that's great news! I'll look into removing the .BAT files from the boot process. If I can manage to do that, that definitely seems like the easiest way forward for everyone! I'll stop what I was doing and focus on this for the rest of the afternoon and report back with any progress :-) |
Thank you so much for this, it means a lot, and I'm sure our music teacher will be overjoyed to hear it and will be happy to know she's going to be able to continue using Sonic-pi in the future. |
Wait until your music teacher learns about the new Link functionality in v4. The whole class will be able to jam together (assuming your networks haven't clamped down on sending local UDP packets via Multicast ;-) |
I just got Sonic Pi booting on Windows without using any .BAT files :-) It all needs quite a bit more polish, but I'll have a BETA msi installer ready for Monday for you to try... |
Please could you send me an email at samaaron [at] gmail so I can send you the link when it's ready. |
On some Windows clusters security policies have been set which precludes users from using CMD on Windows. This means that cmd.exe isn't available and also that .bat files cannot be run. In v4 Sonic Pi switched from basic Erlang to Elixir releases which are managed by .bat files. This has caused booting errors on those systems. This patch removes the need to use .bat files in the booting process on Windows. * ENV vars are set in the daemon rather than the tau boot script (for all platforms) * tau boot script is no longer used on Windows for prod mode - instead the path and arguments to erl.exe are hard coded A similar approach to other platforms for avoiding using the tau boot script in prod mode should be tested and possibly committed in the future. Addresses #3207
Closing this issue as it was fixed with v4.2 :-) |
Recently was asked to update our sonic pi install in our music classroom to the current 4.* release as students had asked for it, however after deploying the MSI. Several computers now exhibit the same behaviour whenever students try to open the software. Running as an administrator allows the software to open and work as expected, but switching back to a student reverts the behaviour. Bizarrely, all computers are imaged the same but not all of them do this, only around half of a total of 15.
The event viewer turns up the following information and I've noticed that it's not creating the .sonic-pi folder in the student's local c:\users*username* directory but the users have full access to this location so can't understand why? Not sure if any other location logs might be generated to explain this issue, but if someone can point me in the right direction, I'd be happy to provide them.
Log Name: Application
Source: Application Error
Date: 08/09/2022 20:47:57
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: MP22-03-15.************
Description:
Faulting application name: sonic-pi.exe, version: 0.0.0.0, time stamp: 0x630e2cae
Faulting module name: ucrtbase.dll, version: 10.0.19041.789, time stamp: 0x2bd748bf
Exception code: 0xc0000409
Fault offset: 0x000000000007286e
Faulting process id: 0x26e4
Faulting application start time: 0x01d8c3bbe3ff2a2a
Faulting application path: C:\Program Files\Sonic Pi\app\gui\qt\build\Release\sonic-pi.exe
Faulting module path: C:\WINDOWS\System32\ucrtbase.dll
Report Id: 653f5818-d6c4-49db-8848-4bf6b2196d22
Faulting package full name:
Faulting package-relative application ID:
Event Xml:
1000
0
2
100
0
0x80000000000000
1902
Application
MP22-03-15.********
sonic-pi.exe
0.0.0.0
630e2cae
ucrtbase.dll
10.0.19041.789
2bd748bf
c0000409
000000000007286e
26e4
01d8c3bbe3ff2a2a
C:\Program Files\Sonic Pi\app\gui\qt\build\Release\sonic-pi.exe
C:\WINDOWS\System32\ucrtbase.dll
653f5818-d6c4-49db-8848-4bf6b2196d22
The text was updated successfully, but these errors were encountered: