Crash executing Search - Locate File in Drives

[rbc]

Hi, I was trying to go from the my currently being edited document do it's location in the Drives side panel. I utilized the Search - Locate File in Drives macro from the Macro side panel, whose source is detected as file_synch_drives.py.

Executing the macro results in an immediate crash, with the ZeusErr.log containing the line:

Code: Select all

ASSERT    "d:\projects\Zeus IDE\Apollo\zfwtag01.cpp" (2719)

I don't have a D: drive on the PC.

[jussij]

I don't have a D: drive on the PC.

That line in the log file is the location in the Zeus code base that cause the issue and that line does indicate something strange has occurred

Looking at that line of code, there are no obvious indication of what might have gone wrong, which indicates this might have been some kind of timing related issue.

If that is the case, it will be difficult to find a fix, only because without an easy way to replicate a bug at will, they are impossible to fix

For example, I suspect if you run that Search - Locate File in Drives macro over and over again, it will work fine each and every time.

However, if you do find a way to replicate the crash at will post those details, only because then it should be easy to replicate the bug at this end and then find a fix

Jussi

[rbc]

Actually I have been able to reproduce it everytime on my machine by executing the Locate File in Drives macro. This is true whether I use the side panel of macros, or go through the Macros menu, or use the shortcut.

[jussij]

This is how I test this macro:

• I am using the 64 bit version of Zeus running on Windows 10
• I start Zeus with no files open. Zeus opens on the workspace panel and that pane; shows no workspace open.
• I drag and drop the readme.txt from the Zeus install folder.
• Using the Macros, Search, Locate File in Drives menu, I am able to locate the readme.txt file which activates the Drives panel and shows the correct file location.
• That Macros, Search, Locate File in Drives menu shows the macro is also bound to the Alt+F3 key. I can rapidly hit that key a half dozen times; the macro is run and once again the expected result are produced.
• If I select the Macros panel and run the macro using that approach, I once again get the exact same result.

So, for me the macro works just fine.

I have been able to reproduce it everytime on my machine by executing the Locate File in Drives macro.

If you can replicate the problem at will, then there must be something very specific to what you are doing that is then causing the error.

But unfortunately, without finding a way to replicate the issue at this end it is impossible to fix

Jussi

[rbc]

I tried this on another PC, but the macro in question works fine. There is no crash and it correctly narrows down to the directory where the file is located. It could be something very machine specific, since even on this PC where the macro worked, I don't have a D: drive mapped.

[jussij]

I tried this on another PC, but the macro in question works fine.

If you are seeing a proper Zeus crash on the other machine, you should also be seeing the Zeus crash dialog.

That dialog is a message box telling the user Zeus has crashed, and it also gives the location of the ZeusErr.log log and the Zeus Err.dmp crash dump files.

You can copy the text of the message using Ctrl+C and if find the two files mentioned in the message, add them to zip file and send them through as an e-mail attachment.

The crash dump in particular sometimes helps to fix these issues, as it provides a lot more information about the crash.

But depending on where the crash happens, sometimes that file is not created

I don't have a D: drive mapped.

The D: drive reference is not related to this issue. This is just a file location in the Zeus code base where something unexpected happened.

In this case this is the line 2719 in the Zeus zfwtag01.cpp file:

Code: Select all

TagWorkspace::~TagWorkspace()
{
  //-- check the workspace has been cleaned up before this static destructor is called
  ASSERT(pWorkspace == 0);
}

The ASSERT fired because the pWorkspace was not zero as expected.

So, while the ASSERT doesn't identify the cause of the issue, it does show something strange is happening.

Jussi

[rbc]

Hi Jussi, the first time around a ZeusErr.dmp file was created in the installation directory with a size of about 22.2 MB. There was no message box dialog about the crash though. Unfortunately since it only occurred on my work machine, I'm unable to upload and send those files to you. My home installation works fine, so I'm guessing it's very machine specific and not a widespread issue.

[jussij]

One of the issues with modern day work environments; virus checkers are generally set to be extremely aggressive, despite the fact they are most likely identifying false positives.

A random issue like this could well be something like a virus checker pulling the rug from under some basic Zeus action, thinking it was stopping some kind of virus attack.

Jussi

PS: For some context, on my Windows 10 development machine the Zeus 32 bit has been killed by Windows Defender at least a two dozen times. Each time this happens the exact same executable is reported to Windows Defender as a false positive and every time the executable has been clear.

The problem is, every time Zeus is rebuilt the exe file changes (i.e. at a minimum the Microsoft Compiler changes the time stamp), meaning this is a never-ending episode of whack a mole. What is strange, the 64 bit version only gets hit every now and again.