Matlab getting stuck at p-code "alternategetframe" inconsistently

I have some code that I have run several times over the last year. I am trying to run the same code now for the past 2-3 days after a few months hiatus, during which I have upgraded my laptop and I think upgraded to R2025a as well. Before these events I had no trouble with this code executing. Now, I find that it hangs randomly (even as long as overnight).

After a lot of debugging, it seems to me that it usually gets stuck on a call to some p-code in the graphics toolbox, under printer - called "alternategetframe". I have checked that this p-file exists, and is in a private directory under toolbox/matlab/graphics/graphics/printer, which contains a .m file called "getframe". The p-code is called by this "getframe" function, and the path settings contains the location of "getframe".

I don't understand why this happens or what to do about it. This never used to happen, and I wasn't even aware of the call to "alternategetframe" before. Even now, it happens inconsistently - meaning that it freezes most of the time I run the code, but has executed fine a couple of times.

Since "alternategetframe" is a Mathworks' p-file, I can't dig any further into it to identify the exact problem. I would appreciate some help on what might be happening.

[AR]

I forgot to mention that I am experiencing better luck (these last few days) placing breakpoints, entering debug mode, and continuing. Sometimes, this gets me across the problem area and completes execution, although not always.

[dpb]

Submit this to Mathworks as an official support request/bug at <Product Support Page>.

It more than likely has to do with the new desktop and something particular with your system -- perhaps a video board/chipset or the like.

You might try seeing if there are any vendor-specific updates to drivers as one possible action you could take. Also be sure you've installed any patches/updates to the MATLAB release you're running.

[AR]

Thanks. When I get some downtime from running code, I will check on patches.

Regarding drivers, this is a central-IT-administered machine and I can't install any drivers myself and have to rely on whatever appears from regular software updates. I have tried to get the renderer to point to my actual GPU (changing from the default integrated-graphics that it was set to) by applying this setting in Windows. However, since the release doesn't any longer support the use of the opengl command, I can't try forcing it off of hardware acceleration (web searches recommend trying "opengl software" for other problems potentially relating to rendering/drivers, etc). I don't know of an alternative to get it to use software vs. hardware acceleration. Please keep in mind that I understand nothing of low-level software engineering matters.

In the meanwhile, I am getting by from sporadic success in execution by combinations of Matlab restarts, PC restarts, and debug-mode. If this becomes untenable, I will raise a support request.

[dpb]

In such an institutional environment where this clearly impacts your productivity, I'd think it would be a case of raising an internal IT support ticket to fix their installation on an employee machine. But, of course, your internal ogranization environment is what it is you have to deal with.

[AR]

In the meanwhile, can someone tell me if there is a way to force software rendering vs. hardware acceleration as of R2025a? I don't know if this will help but it seems close to the problem at hand.

[dpb]

See rendererinfo With R2025x, the opengl functionality has been neutered and supposedly "everything just works". The issue is there is essentially an unlimited number of chipset and driver combinations and Mathworks can't test every possible combinatin so some will inevitably have issues.

Try

rendererinfo

and

rendererinfo(obj)

where obj is the graphics object handle into which you app is plotting to see what is being found/used.

You might find the <following thread> interesting to see a discussion of how stuff is put together and that underneath it all is still the equivalent of OpenGL by a different guise besides the hardware renderers on you particular machine.

Again, getting anything fixed boils down to updating drviers first and then getting Mathworks involved if there are still problems unless your internal IT people are willing and competent-enough to dig into the specifics on your system. They've got it now where there really isn't anything the average end user can do.