Exception thrown in Rider running version 5.14.0.5

Hey. Thank you for your indispensable tool.

In Rider i get the following IDE internal errors once or twice a day. The IDE stalls for 10-15 seconds but neither Rider or NCrunch stops working. There appears to be no clear pattern in when this appears.

Have a nice day.

java.lang.Throwable: Do not call `getChildren(null)`. Do not expand action groups manually. Reuse `AnActionEvent.updateSession` by composing, wrapping, and postprocessing action groups. Otherwise, use `getChildActionsOrStubs()` or `getChildren(ActionManager)`
at com.intellij.openapi.diagnostic.Logger.error(Logger.java:375)
at com.intellij.openapi.actionSystem.DefaultActionGroup.reportGetChildrenForNullEvent(DefaultActionGroup.java:373)
at com.intellij.openapi.actionSystem.DefaultActionGroup.getChildren(DefaultActionGroup.java:367)
at com.remco.software.ncrunch.NCrunchStartupActivity.updateMenuActionsRecursively(NCrunchStartupActivity.kt:118)
at com.remco.software.ncrunch.NCrunchStartupActivity.execute(NCrunchStartupActivity.kt:90)
at com.intellij.ide.startup.impl.StartupManagerImplKt$launchActivity$1.invokeSuspend(StartupManagerImpl.kt:493)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:608)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:873)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:763)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:750)

java.lang.Throwable: Do not call `getChildren(null)`. Do not expand action groups manually. Reuse `AnActionEvent.updateSession` by composing, wrapping, and postprocessing action groups. Otherwise, use `getChildActionsOrStubs()` or `getChildren(ActionManager)`
at com.intellij.openapi.diagnostic.Logger.error(Logger.java:375)
at com.intellij.openapi.actionSystem.DefaultActionGroup.reportGetChildrenForNullEvent(DefaultActionGroup.java:373)
at com.intellij.openapi.actionSystem.DefaultActionGroup.getChildren(DefaultActionGroup.java:367)
at com.remco.software.ncrunch.NCrunchStartupActivity.updateMenuActionsRecursively(NCrunchStartupActivity.kt:118)
at com.remco.software.ncrunch.NCrunchStartupActivity.updateMenuActionsRecursively(NCrunchStartupActivity.kt:119)
at com.remco.software.ncrunch.NCrunchStartupActivity.execute(NCrunchStartupActivity.kt:90)
at com.intellij.ide.startup.impl.StartupManagerImplKt$launchActivity$1.invokeSuspend(StartupManagerImpl.kt:493)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:608)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:873)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:763)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:750)

I came here to report these. This didn't start with the latest nCrunch - but it might have started with Rider 2025. Rider tells us to report this to you - the report to JB buttons are greyed-out.

Thanks for sharing these. These errors started showing up with Rider 2025.1. As far as I can tell, they don't seem to have a functional impact on the IDE - They seem to be warning about an API misuse; something that should be corrected to implement best practice.

Did the errors seem to be triggered with your performance issue? Or did you find them in the log after you went searching for a reason?

Hey Remco.

I did first notice the issue after upgrading to 2025.1. I currently have 2025.1.2 installed and still se the issue. After the 10-15 second stall the IDE and NCrunch plugin continues to run unaffected, but the stall is a little annoying ;)

It is hard to tell if it is triggered by or triggers the performance issue, but the error timestamp and the time of the performance degradation overlap.

Lasse

Does Rider give you an opportunity to dump the call stack when the stall happens? It would be rather perplexing to see the stall being related to this error. I do intend to look at fixing the error, but solving the stall is going to require much more detailed information.

I don't think I can dump the call stack but I will se what intel I can gather next time it happens.

I've prepared a build containing a fix for the getChildren error described above. Would you be interested in trying it out to see if it has any affect on the stall?

NCrunch_Console_5.15.0.3.msi
NCrunch_Console_5.15.0.3.zip
NCrunch_GridNodeServer_5.15.0.3.msi
NCrunch_GridNodeServer_5.15.0.3.zip
NCrunch_LicenseServer_5.15.0.3.zip
NCrunch_Rider_5.15.0.3.7z
NCrunch_Rider_5.15.0.3.zip
NCrunch_VS2010_5.15.0.3.msi
NCrunch_VS2010_5.15.0.3.zip
NCrunch_VS2012_5.15.0.3.msi
NCrunch_VS2012_5.15.0.3.zip
NCrunch_VS2013_5.15.0.3.msi
NCrunch_VS2013_5.15.0.3.zip
NCrunch_VS2015_5.15.0.3.msi
NCrunch_VS2015_5.15.0.3.msi.7z
NCrunch_VS2015_5.15.0.3.zip
NCrunch_VS2017_5.15.0.3.msi
NCrunch_VS2017_5.15.0.3.msi.7z
NCrunch_VS2017_5.15.0.3.zip
NCrunch_VS2019_5.15.0.3.msi
NCrunch_VS2019_5.15.0.3.msi.7z
NCrunch_VS2019_5.15.0.3.zip
NCrunch_VS2022_5.15.0.3.msi
NCrunch_VS2022_5.15.0.3.msi.7z
NCrunch_VS2022_5.15.0.3.zip

Right now I suspect the stall is caused by Rider collecting information about the issue and not the issue itself. I have installed the fix and will give it a spin tomorrow and report back.

lassesjorup wrote:Right now I suspect the stall is caused by Rider collecting information about the issue and not the issue itself. I have installed the fix and will give it a spin tomorrow and report back.

That would make sense. I'm keen to hear whether it solves the problem for you (I can't seem to get it to happen on my end).

I have been running the new version and the issue and the stall seems to be resolved. :)
Thank you

Reverted back to the previous version and the issue returned (as expected ;)).
Did manage to catch a glims of a "dumping stacktrace"ish message from Rider while the stall was happening so I am quite sure that it is whats causing the stall.

lassesjorup wrote:Reverted back to the previous version and the issue returned (as expected ;)).
Did manage to catch a glims of a "dumping stacktrace"ish message from Rider while the stall was happening so I am quite sure that it is whats causing the stall.

Excellent, thanks for confirming this. I'll admit that I didn't expect this, but it's one of those situations where I'm happiest being wrong :)