Hi guys, I have a strange error.
Internal error 01 : Assertion failed: Error: Output corrupted stack
File wsldebug.cpp Line 412
Process PID=8444 Image: C:\Clarion11.1\grmargins\GMargins.exe
Thread 2 Handle=00000B50 TID=11380
Stack frame: 05C3E880
I have been using cw11.13630 without this error.
I then transferred 51 Apps to 11.1.13845
Open customer browse, say 10 times, 11th time brings error.
Sometimes it happens on first or second opening, other times I can open the browse 30 times before the error happens.
I hide the Window on opening as I do a lot of real estate.
At the end of the real estate, I unhide(0)
This line brings the error. The unhide does it. Error always line 412,
Any suggestions ? Thanks.
Reason: the message to put to the log file (C11LOG.TXT in the current directory) is too long.
Please, provide that file and the file generated from the run-time error dialog.
Thanks for reply, also. Sorry, there is no TXT file, just the LOG file which contains the names of the DLL`s and a lengthy list of thread stacks. I have not found out how to upload the file to this site. Sometimes there is no error message at all, just the outline of the frozen Window. I find where the error is by adding to my own log file the functions called on opening.
This is possible. Generally, the shipping release-mode RTL can generate this log in case of the heap failure only.
It would be very useful.
Use the button
on the top of the message write box.
Thanks again for your reply.
I located the TXT file, it is just two lines
Assertion failed: Error: Output corrupted stack
File wsldebug.cpp Line 412
I renamed the .LOG to .TXT else it does not show
to upload it.
RT_ERROR-240322-144118.txt (26.9 KB)
Thanks again for your help.
Further testing.
It only happens on a threaded procedure with a menubar.
Take the menubar out and no fails.
With menubar, open non threaded, no fails.
13630 no corrupted stack either way,
13845 happens randomly only on threaded procedure with menubar.
Thanks. If you can reproduce the problem using the run-time library (CLARUN.DLL) from the
<your CW installation>\BIN\Debug directory, the produced error report would be useful for more exact decoding of the call chain.
This is not required - I decoded the stack content from the provided run-time error report.
- The run-time error occurred because the function in WSLDEBUG.CPP has the variable number of parameters but the 0 marking the end of parameter list was not pushed by the caller. Probably, there is a mismatch in declarations.
- The function in WSLDEBUG.CPP was invoked because of attempt to free a block that was freed already. This block was used for the font object using to draw text in themed menus. I do not see where else that font object can be disposed from. And unfortunately, the stack content can’t show when and where such disposing happened. I’ll try to reproduce the issue.
This is OK. The real reason why execution went by the branch to show the run-time error dialog are 5 dwords on the stack appeared after call to some Windows API function. As result value in the ESP register became wrong and the condition to check the stack consistency evaluated as the stack corruption.
It would be very desirable to have the program demonstrating the problem for debugging.
Thank you so much, Alexey, for all your time. I really appreciate it.
Unfortunately I will be out on the road for the next two days, and can only get back on Wednesday. I make several calls to source procedures between HIDE(0) and UNHIDE()), creating controls for the Window and re-positioning items, but nothing to do with the menubar so far as I can see, My program is far too big to upload here, but I will see if I can reproduce a simple one to show the error. Thank you again.
I have things to do 
The run-time error’s log shows two problems that I can’t explain. It would be useful to find their roots.
The font object to use in drawing menus can be reset as a part of drawing. Windows “decides” when to redraw menu items.
Thank you for your continued interest.
Attached a text file with more information.
Alexey.txt (5.7 KB)
I think, I’ve understood why font objects can be freed twice. The problem is that I can’t reproduce the problem. So, I’m not sure that the proposed fix works.
I guess, the program where the problem occurred STARTs multiple popup windows with their own menus?
Thank you, Alexey, for your work on this. Yes, multiple started windows, sometimes opening the suppliers, for example, on the second open, triggers the exception, sometimes on twentieth open. In 13630 I opened 50 times with no exception. Here are two screenshots doing the same thing in the different versions.
Do all opened windows use the same menu style?
Yes, same style, though some windows have more menu items than others.
Thanks. I’ll send proposed fix to SV. Of course, I can’t guarantee that it is being included to the next release.
1 Like
Thank you so much for all you do.