Menu
▾
▴
#2284 SciTE exit with exception 0x5
Platform: win32 on Windows 7
Use of -loadsession: can cause an exit with a exception code 0x5, which is usually a access violation.
I have tested with Sc511.exe and Sc512.exe. The issue appeared in Sc512.exe as I use -loadsession: regularly and so previous versions did not exit with this exception.
Put Sc511.exe (optional), Sc512.exe and this batch-file into a empty directory:
@echo off
setlocal
if not exist "test.txt" (
echo test
) > test.txt
if not exist "SciTE.session" (
echo buffer.1.path=SciTE.session
echo buffer.2.path=test.txt
) > SciTE.session
if not exist "Sc511.exe" goto :v512
echo Test: Sc511.exe
echo 1. Close SciTE to exit clean
Sc511.exe -loadsession:SciTE.session
:v512
echo Test: Sc512.exe
echo 1. Close SciTE to exit with exception code 0x5
Sc512.exe -loadsession:SciTE.session
echo Test: Sc512.exe
echo 1. Change tab from test.txt to SciTE.session
echo 2. Close SciTE to exit clean
Sc512.exe -loadsession:SciTE.session
pause
With the last test, if change tab from test.txt to SciTE.session and back to test.txt, it still exits clean. So, it is not which tab to exit with, just changing tabs avoids the exception.
It must be the load session feature as starting Sc512.exe blank and then opening those files does not cause a exit with an exception. Though, opening the files while SciTE is already open is perhaps similar to the effect of changing tabs in the last test.
It is not the SciTE.session file loaded as an entry into the buffer as the line buffer.1.path=SciTE.session can be commented and another text file can used instead and the exception can still occur on exit.
I suspect this entry in history:
- Free document memory when closed instead of recycling document for future opened file.
though has no #link. So, I do not know the exact origin of the issue.
Sc512.exe.NNNN.dmp files are created in the %LocalAppData%\CrashDumps folder.
The brief error details:
Problem signature:
Problem Event Name: BEX64
Application Name: Sc512.exe
Application Version: 5.1.2.0
Application Timestamp: 614bace1
Fault Module Name: StackHash_1dc2
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Offset: 0000000000000000
Exception Code: c0000005
Exception Data: 0000000000000008
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 3081
Additional Information 1: 1dc2
Additional Information 2: 1dc22fb1de37d348f27e54dbb5278e7d
Additional Information 3: eae3
Additional Information 4: eae36a4b5ffb27c9d33117f4125a75c2
It is not just
-loadsession. If a file is opened and other files opened, save a file and then close SciTE can cause the exception code 0x5. The exception can occur with multiple scenerios based on the exit of SciTE. The issue is wider than what I thought in the original post.I don't see any problems on Windows 10 with the batch file.
Can reproduce this now. The attached patch may fix it by finalizing loading of background tabs at shutdown.
So far no exception when recompiled with the patch. I'll let you know if it does not solve the issue over time. Thankyou.
Out of interest, I tested the script I posted in Windows 10 Virtual Machine and was not causing the exception. Windows 7 appears to be more vunerable. Might be a good sign for the issue to affect less users.
This may sound odd. Run Sc1.exe in
scite\binand close window, OK. Run SciTE.exe inscite\binand close window, exception code 0x5 with fault module name of lexilla.dll. Both runs are with blank panes, no files loaded. This is in Windows 7.Started Windows 10 Virtual Machine. Copied
scite\bininto VM and did same tests. No exception.I did a clean and recompile and the results are the same.
Should try to get a stack trace by, for example, running inside a debugger.
Used WinDbg on crashdumps and did a run of Sc512.exe with
-loadsession:SciTE.session.Not very detailed in my view. WinDbg does not offer much. It has a call stack list with several entries in a list.
Listed like:
I use the TDM-GCC compiler for recompiles.
I tried x64dbg which shows mostly disassembly.
Nothing I view points to a source line as an issue.
Noticed version 513 posted, will test with it.
Quick test OK so far.
Last edit: Michael Heath 2021-09-24
Are you running any Lua scripts? Or Scintillua for lexers?
Any
lexilla.contextproperties set?The tests were isolated with minimal files, just like instruction in the initial post.
My permanent SciTE setup does have lua scripts, though only way to know if something is or is not related is to isolate with original files in an empty directory, in which I do the test. My permanent SciTE setup does not use a name like Sc512.exe, it is always SciTE.exe, even though it is of the type Sc1. It is self contained as I use environmental variables so that all property and lua files are located within the SciTEDefaultHome directory.
I do not use Scintillua.
I do not know what SetLibraryProperty is. It is in the 1st crash dump analyzed in the link in previous my reply, so the Call Stack probably gets it's information from the STACK_TEXT section.
I had to check what lexilla.context is in the doc. I do not use, nor ever used any property starting with lexilla.
The crashdumps folder allows up to 10 files, though I deleted the existing files to start fresh and produce the 3 files which were analyzed by WinDbg.
The crash dumps make little sense to me. Perhaps a knock on effect that triggers different targets, like lexilla, then scintilla, then lua subsystem... that I do not understand.
This download contains the equivalent of Sc513.exe with a PDB file to show more symbols. The PDB should be in the same directory as the EXE.
https://www.scintilla.org/Sc1Debug.zip
To make in a similar similar way producing a PDB file, build with
DEBUG=1:I may have troubles trying to get Sc513.exe to exit with exception. Sc512.exe is the nasty build that I expect to exit with exception. If you can build Sc512.exe with PDB, that might be better to analyze.
I do not have nmake which AFAIK exist only in Visual Studio. I have mingw32-make which unfortunately does not make PDB files. It has a GDB debugger which uses python39.dll, which is incompatiable with Windows 7. The last Python Windows 7 can use is 3.8.2 and that is a repacked installer to workaround the official installer that checks for Windows 7.
Bugs in a previous release aren't really interesting unless they are also present in the current code.
An easy way to get nmake and other tools is to download and install the free Visual C++ 2019 Community Edition which will run on Windows 7.
Closing as fixed in 5.1.3.