Add a New Comment (Rich Markup)
( Jump to the original submission )
I have not seen this problem since octave v6. From my side this bug could be closed.
I just updated to V5.1 on windows 7 and will comment here if I see the problem again. Thanks!
No response, asumming this has been fixed in the latest release. Closing report.
Version 4.4.1 is deprecated and no longer supported. Please try with the latest stable release which is 5.1.0. The problem is likely to have been fixed.
Thank you Philip for your constant testing! I am using Octave 64-bit version. There is only a minimum of company installed software and policies on my machine. The files I work on are on a private disk drive, so I can exclude simultaneous access. I have a virus scanner of course, but this should interact with other programs in the same way as with octave. I never experienced problems from this side. My guess goes more to the quite instable interaction of octave with my graphics hardware (Intel HD Graphics 520, Shader-Version 5.0, openGL-Version 4.4, openCL Version 2.0, DirectX Version 11.0). I have posted a few bugs concerning this. I can not exclude that the GUI hangs when trying to change some window focus or whatever graphical operation happening in background.
I'm doing all the time what the OP reports on a variety of Windows PCs (physical HW and virtual / remote, Win10 and Win7), and I never experienced hangs or crashes. The mechanism that Torsten describes works very reliably for me. But then I've been running bleeding edge 5.0.0 development versions (now 6.0.0), not 4.4.1. Maybe that offers hope that in the next release this bug is no more present. To the OP (Georg): Do you run a 32-bit or 64-bit version of Octave? Could it be related to your HW and SW environment? like malware scanners, sysadmin-installed SW that is monitoring for suspect activities of running software, company-wide installed Windows policies, etc? Maybe other users accessing the same file? What you describe smells of the function file on disk being somehow locked by other processes.
Sorry, my description was imprecise in point 5. As you wrote a dialog pops up, you answer "save" to stop debugging and save the file. This is the point where octave GUI frequently stops responding. Currently I have no idea which steps exactly are needed to reproduce the behavior. I experience this behavior 10 or 20 times a day for some of my programs and never for some others. It may have to do with debugging functions vs. scripts. Or it may be triggered by a certain level of nested function calls?
Thank you for the report. The steps to reproduce are not fully clear to me. When editing a function that is currently debugged, i.e., the debugging pointer is in the related file, saving the file opens a dialog. This dialog allows to stop debugging and save the file or to cancel saving the file. Therefore, it is not possible to stop debugging in step 5 after having saved the file in step 4.
During debugging a function I often make changes to the function to correct its behavior. The GUI frequently hangs when saving this changes before stopping debugging. This does not happen every time but when doing it frequently it does happen sooner or later. Steps to reproduce are:
(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)
Attach Files: Comment:
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Only project members can vote.
Please enter the title of George Orwell's famous dystopian book (it's a date):
Follow 2 latest changes.
Copyright © 2023 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team. Source Code
Powered by Savane 3.11