Let’s promote a testing team for fluidnc lol. Man i just love my old stable early 3.7.x version with v2ui.
Bah. I can’t run anything from SD either. It goes into alarm. I could definitely do this with pre9.
1 Like
okay I will ping them.
That last little merge at the end (Spindle stuff) may be related?
You captured a good crash dump so be sure to include that.
Moving from discord to github now, per Bart.
2 Likes
For completeness, can you confirm that your file works fine with 3.8.4-pre9?
1 Like
yup, I will add that to the issue
I have to assume that PR #1346 is the issue.
Thats the only commit I think affecting the main code that wasn’t in pre9
Not really good practice to merge a feature branch into main, and immediate release. I have to assume he missed the fact that those commits weren’t included in his branch because it was so long ago.
4 Likes
As someone who manages git branching and releases for software in the nuclear power industry, this all feels like the wild wild west to me. In my opinion, they should do feature branches off of a development branch, PR development into a release branch for pre-releases, and PR the release branch into main for official releases. Or they could skip a release branch but build pre-releases off a development branch. And have separate feature branches. That SteppingNoVTabs branch got really carried away. They shouldn’t have done pre-releases missing things in main.
They used to have a Devt branch, but it was worse that way.
The merges kept getting jacked and code getting lost.
It’s actually been better this way 
In theory, all those things are recommended, but for people who don’t know git well, the extra branches get a little tricky.
I deal with it at work as well. A lot of people just struggle moving from traditional source control to something like git. 
1 Like
But yes, their development branch setup was better if it would have been used properly.
Currently, they have no branch that remains constantly stable for patch releases
1 Like
I don’t want to muddy the water by commenting on the Github issue, but here is what I captured from the Platformio serial monitor so it includes the stack trace:
Grbl 3.9 [FluidNC v3.9.0 (wifi) '$' for help]
WebSocket disconnect 0
[MSG:INFO: WebUI: Request from 192.168.0.120]
Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled.
Core 1 register dump:
PC : 0x400e4965 PS : 0x00060530 A0 : 0x800dcc3c A1 : 0x3ffb20b0
A2 : 0x00000000 A3 : 0x00000001 A4 : 0x80000020 A5 : 0x00000007
A6 : 0x00000005 A7 : 0x00000001 A8 : 0x00000000 A9 : 0x3ffb2090
A10 : 0x580ea9b9 A11 : 0x3ffc643c A12 : 0x3ffc6339 A13 : 0x3ffc57b4
A14 : 0x00003a97 A15 : 0x3f40d0d8 SAR : 0x0000001d EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000000 LBEG : 0x4008bbe8 LEND : 0x4008bbfe LCOUNT : 0xffffffff
Backtrace: 0x400e4962:0x3ffb20b0 0x400dcc39:0x3ffb20d0 0x400dcc6c:0x3ffb2100 0x401fdca1:0x3ffb2120 0x400fc275:0x3ffb2150 0x400fc5f5:0x3ffb21b0 0x400fc665:0x3ffb21d0 0x400fd6b1:0x3ffb2210 0x400ee0e4:0x3ffb2250 0x40128d81:0x3ffb2290
#0 0x400e4962 in Job::save() at FluidNC/src/Job.cpp:37
#1 0x400dcc39 in _ZL7runFilePKcS0_19AuthenticationLevelR7Channel$isra$58 at FluidNC/src/FileCommands.cpp:257
(inlined by) runFile at FluidNC/src/FileCommands.cpp:251
#2 0x400dcc6c in runSDFile(char const*, AuthenticationLevel, Channel&) at FluidNC/src/FileCommands.cpp:269
#3 0x401fdca1 in WebCommand::action(char const*, AuthenticationLevel, Channel&) at FluidNC/src/Settings.cpp:539
#4 0x400fc275 in do_command_or_setting(char const*, char const*, AuthenticationLevel, Channel&) at FluidNC/src/ProcessSettings.cpp:898
#5 0x400fc5f5 in settings_execute_line(char*, Channel&, AuthenticationLevel) at FluidNC/src/ProcessSettings.cpp:1024
#6 0x400fc665 in execute_line(char*, Channel&, AuthenticationLevel) at FluidNC/src/ProcessSettings.cpp:1041
#7 0x400fd6b1 in protocol_main_loop() at FluidNC/src/Protocol.cpp:289 (discriminator 4)
#8 0x400ee0e4 in loop() at FluidNC/src/Main.cpp:152
#9 0x40128d81 in loopTask(void*) at C:/Users/jeyea/.platformio/packages/framework-arduinoespressif32/cores/esp32/main.cpp:50
ELF file SHA256: e4c469edd0e307f2
It’s that PR.
Looks like he changed job->top() in multiple places
But not in the save() method
I’m on my phone at a football game so I can’t look close, but looks like job is probably null there
@jeyeager you can try using source() there and see if that fixes it for you
3 Likes
That seems like it has some good info, maybe drop it in the github issue?
I learned most of my git from Marlin. They use a bugfix branch and when that gets stable again it gets merged to the main release, usually as a 0.0.1 increment. And when enough things change in the main release, they change the 0.1 rev number higher.
I screw up my own git all the time. I get excited and forget to branch it. Then when I hit merge, it actually merges instead of creating a PR…whoops. Wild West for sure!
1 Like
Those two should be “source”. I have not compiled from source in a while I guess I can give it a try.
1 Like
I was just about to put pre9 back on to get back to a functioning version so I can try it as well.
There may be more issues…… but those 2 stood out.
I hate trying to read things like that from my phone, so I didn’t dig far
2 Likes
Confirmed that fixes it. I’ll comment on the Github issue. Way to figure out the problem from your phone Mike.
4 Likes