Does Zeus have any known issues with Windows 8? I am running 3.97o and have had a couple of problems, including messages about internal errors, and another regarding having used all of the 2GB address space. There is some chance that I brought this on myself by running Zeus both native Windows 8 and in a VirtualBox VM running XP, but both using the same workspace files. However, that's only a possibility, because I'm pretty sure I have also experienced similar instability when I was not running Zeus in the VM (Win8 only).
I was in the middle of a sprint to get some particular functionality delivered, so I didn't do as much problem determination as I should have, but I thought I'd ask if there were any other similar reports.
Bill Diener
Windows 8 Issue?
Hi Bill,
Not that I know of and this is the first such report.
But I myself only use Zeus on Windows XP and Windows 7.
I've not come accross any of these
I would suggest checking the task manager to see if Zeus is growing its memory footprint. It may well have used up it's 2Gb quota
Cheers Jussi
Does Zeus have any known issues with Windows 8?
Not that I know of and this is the first such report.
But I myself only use Zeus on Windows XP and Windows 7.
I am running 3.97o and have had a couple of problems, including messages about internal errors
I've not come accross any of these
and another regarding having used all of the 2GB address space
I would suggest checking the task manager to see if Zeus is growing its memory footprint. It may well have used up it's 2Gb quota
Cheers Jussi
It does appear that there is a major memory leak going on, probably with the tag update process. Every time I save a file, the memory usage as shown in task manager jumps. It also appears that the amount by which it jumps is growing each time. For example, I'm now at 194.8Mb, saving jumps to 281.3 MB, saving again jumps to 420.9 MB. I started at just under 50 MB and the first couple saves seemed to grow only by a few MB, then the pace started accelerating.
I have tagging configured to update on workspace load and file save - I turned off the periodic update because it was causing significant delays for me, particularly in the virtual machine I was using. I think I probably still had the periodic update turned on when I first got the 2GB message I mentioned before, so that probably explains why.
I am running right now on Windows 8 directly, no VM involved. The save tests above made NO changes to the file, just saving.
Bill
I have tagging configured to update on workspace load and file save - I turned off the periodic update because it was causing significant delays for me, particularly in the virtual machine I was using. I think I probably still had the periodic update turned on when I first got the 2GB message I mentioned before, so that probably explains why.
I am running right now on Windows 8 directly, no VM involved. The save tests above made NO changes to the file, just saving.
Bill
Hi Bill,
Over the years I've done quite a bit of memory leak testing of the Zeus. Also I generally have Zeus running for days on end without any stop/restart in between and have never notice a memory build up.
But that is not to say one of the more recent changes has not introduced a new leak
In the Keywords section of the Document Type there is a Tag Syntax Highlighting option.
By chance do you use this option
That is a fairly new feature (and is very memory intensive) so it might have a leak
I personally don't use that option.
The Zeus workspace is some 600+ files and I don't notice more than a half second slowdown on these background periodic tag updates
I will do some testing to see if I can create a similar leak at this end.
Cheers Jussi
I'm not yet convinced.It does appear that there is a major memory leak going on
Over the years I've done quite a bit of memory leak testing of the Zeus. Also I generally have Zeus running for days on end without any stop/restart in between and have never notice a memory build up.
But that is not to say one of the more recent changes has not introduced a new leak
The tag process is very memory intensive.probably with the tag update process.
In the Keywords section of the Document Type there is a Tag Syntax Highlighting option.
By chance do you use this option
That is a fairly new feature (and is very memory intensive) so it might have a leak
I personally don't use that option.
I think that is the default and that is the option I also use.I have tagging configured to update on workspace load and file save
What is the size (number of files) of you workspaceI turned off the periodic update because it was causing significant delays for me, particularly in the virtual machine I was using.
The Zeus workspace is some 600+ files and I don't notice more than a half second slowdown on these background periodic tag updates
To confirm this is a tags leak just turn off the option to update tags on save and you should see the leak go away.The save tests above made NO changes to the file, just saving.
I will do some testing to see if I can create a similar leak at this end.
Cheers Jussi
It looks pretty definitely like the tags update process. When I turn the update on save option off for the workspace, I can save files repeatedly with no impact on the memory footprint. I tried it about 30-40 times, and saw no change in the memory usage. When I turned the update on save back on, I started jumping up on memory used with every save, whether the file being saved was changed or not. Over 8 saved, I went from 51.5 MB to 102.5 MB, in increasing size jumps.
To answer some of your other questions:
I don't use the the tags syntax highlighting option.
There are about 400 files in my workspace, a mix of COBOL and C#. My theory was that the timed tag update went through the process for each file in the workspace, while the update on save option would only update for a single file (much quicker, I assume). When I had the timed update option enabled recently, it seemed to be taking on the order of 10-15 seconds, during which Zeus was unresponsive, although I may have been impatient and therefore my time sense might be off. But it was what I thought an unreasonable period of time. Perhaps there is something else going on, but I don't need the timed update option, so I'm not worrying about it.
My experience prior to this with Zeus and memory matches yours - I've used in on XP and Windows 7 in a manner similar to what you outline and have never had any indications of a memory leak. I'm guessing Windows 8, but have no particular reason to suspect that besides it being the obvious thing changed.
Bill
To answer some of your other questions:
I don't use the the tags syntax highlighting option.
There are about 400 files in my workspace, a mix of COBOL and C#. My theory was that the timed tag update went through the process for each file in the workspace, while the update on save option would only update for a single file (much quicker, I assume). When I had the timed update option enabled recently, it seemed to be taking on the order of 10-15 seconds, during which Zeus was unresponsive, although I may have been impatient and therefore my time sense might be off. But it was what I thought an unreasonable period of time. Perhaps there is something else going on, but I don't need the timed update option, so I'm not worrying about it.
My experience prior to this with Zeus and memory matches yours - I've used in on XP and Windows 7 in a manner similar to what you outline and have never had any indications of a memory leak. I'm guessing Windows 8, but have no particular reason to suspect that besides it being the obvious thing changed.
Bill
My experience prior to this with Zeus and memory matches yours - I've used in on XP and Windows 7 in a manner similar to what you outline and have never had any indications of a memory leak.
The reality with memory leaks is it doesn't usually take too long for them to get reported.
Many years ago there was a leak in the Navigator, Drives panel that I never noticed, but a Zeus user who used that feature a lot soon found and reported it
I'm guessing Windows 8, but have no particular reason to suspect that besides it being the obvious thing changed.
I will test this on Windows 7 and Windows XP just to make sure. I would not have thought Windows 8 would have been the problem
Cheers Jussi
Hi Bill,
Is your workspace and the files it contains on a network drive
I have been reading that Windows 8 does does seem to have an issue whereby certain *network activity* can cause memory to leak and the more network activity, the bigger the leak.
If this is the case, if you then copy the workspace/files to a local drive, repeat the tags build on save and you don't see any leak then I think it is safe to say you have run into this Windows 8 leak.
Cheers Jussi
Is your workspace and the files it contains on a network drive
I have been reading that Windows 8 does does seem to have an issue whereby certain *network activity* can cause memory to leak and the more network activity, the bigger the leak.
If this is the case, if you then copy the workspace/files to a local drive, repeat the tags build on save and you don't see any leak then I think it is safe to say you have run into this Windows 8 leak.
Cheers Jussi
Nope, the files are all on the local machine. My machine has an SSD C drive and 2 SATA drives as E and F. The files are all actually on E:, but there is an NTFS junction from C: that points to the E: drive, so you can see the same files/directory structure using C: or E:. The junction thing is probably completely irrelevant to the issue.
When I edit/compile in the XP Virtual machine, it MIGHT access the files as if they were on a network drive - using NET USE shows the paths as networked. But I'm not testing that way for the results I reported - those were all from the local machine running windows 8. No VM or network access involved.
When I edit/compile in the XP Virtual machine, it MIGHT access the files as if they were on a network drive - using NET USE shows the paths as networked. But I'm not testing that way for the results I reported - those were all from the local machine running windows 8. No VM or network access involved.
Unfortunately I don't have access to a Windows 8 machine to do any testing 
But I ran a test on Windows XP and Windows 7 where I had a large workspace (500+ files) open and then wrote a macro to modify a file and then save that file.
I then batch ran that macro 200 times while watching the task manager and I say very little in the way of an increase in memory usage. In other words I'm not seeing a memory leak.
Cheers Jussi
But I ran a test on Windows XP and Windows 7 where I had a large workspace (500+ files) open and then wrote a macro to modify a file and then save that file.
I then batch ran that macro 200 times while watching the task manager and I say very little in the way of an increase in memory usage. In other words I'm not seeing a memory leak.
Cheers Jussi
I ran similar tests on Windows 7 and Windows XP, and I would agree with your conclusions there. On Windows XP, I saw virtually no change, in fact memory footprint seemed to cycle up AND down. On Windows 7, I say an increase of about 50K with each cycle.
I then returned to the Windows 8 machine to repeat the tests. This time, however, I ran a tag rebuild before doing anything. This was in a previously running instance of Zeus. Before I ran the tag rebuild, the memory footprint was about 121MB. After running the tag rebuild, it dropped to 72.8MB. After doing that, I saw absolutely no change in memory footprint as I saved files, and I confirmed that the update on save box WAS checked.
I don't have any explanation for the the behavior I saw before, where the memory footprint was growing by progressively larger amounts. Perhaps the tag file was corrupted in some way that the rebuild fixed, and this was causing the update process to leak somehow? I do have the option to update on workspace open enabled, but I don't know whether that's the same as a rebuild or more like an update for any workspace files that may have changed outside of Zeus?
In any event, I am not seeing that memory leak behavior now, so I'm happy, with the caveat that it would be nice to have some explanation of what was going on and some confidence that it wasn't going to happen again, at least not without making the cause somewhat more obvious and repairable.
Bill
I then returned to the Windows 8 machine to repeat the tests. This time, however, I ran a tag rebuild before doing anything. This was in a previously running instance of Zeus. Before I ran the tag rebuild, the memory footprint was about 121MB. After running the tag rebuild, it dropped to 72.8MB. After doing that, I saw absolutely no change in memory footprint as I saved files, and I confirmed that the update on save box WAS checked.
I don't have any explanation for the the behavior I saw before, where the memory footprint was growing by progressively larger amounts. Perhaps the tag file was corrupted in some way that the rebuild fixed, and this was causing the update process to leak somehow? I do have the option to update on workspace open enabled, but I don't know whether that's the same as a rebuild or more like an update for any workspace files that may have changed outside of Zeus?
In any event, I am not seeing that memory leak behavior now, so I'm happy, with the caveat that it would be nice to have some explanation of what was going on and some confidence that it wasn't going to happen again, at least not without making the cause somewhat more obvious and repairable.
Bill
Perhaps the tag file was corrupted in some way that the rebuild fixed, and this was causing the update process to leak somehow?
I suspect that was indeed the cause.
Over the years I have seen similar issues with the tags database and like you I found the problem was fixed with a rebuild.
I should have suggested the rebuild option myself
I do have the option to update on workspace open enabled, but I don't know whether that's the same as a rebuild or more like an update for any workspace files that may have changed outside of Zeus?
The option always does a tags database update and yes that update will check all the files in the workspace.
For the update Zeus tries to make sure the file structure found in the workspace matches the structure stored in the tags database so naturally that might mean adding or removing files from that database.with the caveat that it would be nice to have some explanation of what was going on
It also checks that the tags for each of the files is the workspace are up to date.
The rebuild process is much simpler as it just deletes the tags database and then creates a new database that matches exactly the file structure of the workspace.
I think the bug is somewhere in the update process when files are removed from the workspace. When a file is removed, the tags for that file also need to be removed from the database. I think sometimes that does not happen but instead orphaned tags are left in the database.
But unfortunately that bug is intermittent so it is hard to track down
Cheers Jussi
The memory consuming behavior is back. When I save the file, the memory footprint grows by a progressively larger amount.
For example, right now it's 76.9, the 78.0, 78.8, 81.9, 89.4, 101.1, 120.5, 152.6, 204.5, 288.1, 426.5, 646.4, 1005.6. Each time I am pressing only Ctrl-S, and waiting until Zeus's CPU usage returns to 0% and the memory footprint stops changing.
If I rebuild the tags, without exiting Zeus and restarting, the memory footprint drops back to 79.1, slightly larger than the 76.9 that is was after the last tags rebuild.
If I exit and restart Zeus (with the same workspace), the memory footprint is 48.5. It then takes about 15 saves to push the footprint up to over 1000, and again running the rebuild drops that back to 67.8, or about 20 greater than it started with.
All of this is being done without ever changing a single character of the file. I suppose my workaround for the moment is just to turn the tags update off and manually rebuild when I think of it, but that seems kind of painful. The memory footprint is unchanging through repeated saves when I have the tag rebuild options turned off.
Please let me know what I can do to help track this down.
On a side note, it appears that the "Disable the automatic updating of the workspace tags file" option in fact disables the ability to manually rebuild the tags file too.
Bill Diener
For example, right now it's 76.9, the 78.0, 78.8, 81.9, 89.4, 101.1, 120.5, 152.6, 204.5, 288.1, 426.5, 646.4, 1005.6. Each time I am pressing only Ctrl-S, and waiting until Zeus's CPU usage returns to 0% and the memory footprint stops changing.
If I rebuild the tags, without exiting Zeus and restarting, the memory footprint drops back to 79.1, slightly larger than the 76.9 that is was after the last tags rebuild.
If I exit and restart Zeus (with the same workspace), the memory footprint is 48.5. It then takes about 15 saves to push the footprint up to over 1000, and again running the rebuild drops that back to 67.8, or about 20 greater than it started with.
All of this is being done without ever changing a single character of the file. I suppose my workaround for the moment is just to turn the tags update off and manually rebuild when I think of it, but that seems kind of painful. The memory footprint is unchanging through repeated saves when I have the tag rebuild options turned off.
Please let me know what I can do to help track this down.
On a side note, it appears that the "Disable the automatic updating of the workspace tags file" option in fact disables the ability to manually rebuild the tags file too.
Bill Diener
Each time I am pressing only Ctrl-S, and waiting until Zeus's CPU usage returns to 0%
What level does the CPU hit on a tags rebuild
When I do a rebuild it hits about 20%.
I'm not seeing any of these memory issues even though I'm constantly using an switching workspaces, but I'm not running Windows 8.0
Please let me know what I can do to help track this down.
Unfortunately it is very difficult to fix any issue if it can't be easily replicated
I will look to fix that.On a side note, it appears that the "Disable the automatic updating of the workspace tags file" option in fact disables the ability to manually rebuild the tags file too.
Cheers Jussi