0

I've faced a really odd behavior of Delphi VCL Styles. With VCL styles enabled, and when madExcept has the "instantly crash on buffer overrun" option activated, the menus become non-styled.

Turning this option off, or switching it to "instantly crash on buffer UNDERrun" fixes the menus issue.

Questions are: did anyone else encounter this issue? Why it happens and how to fix it?

djsoft
  • 1,051
  • 8
  • 19

2 Answers2

4

This issue is caused by a internal call to the GetClassName WinAPI function. I just tested and uploaded a fix for that. So you can download the last version of the VCL Styles Utils project from the repository, then add the units Vcl.Styles.Utils.Menus, Vcl.Styles.Utils.SysControls and Vcl.Styles.Utils.SysStyleHook to your project and finally comment or remove the Line (27) {$UNDEF UseVCLStyleUtilsMenu} in the Vcl.Styles.Utils.Menus unit.

RRUZ
  • 134,889
  • 20
  • 356
  • 483
  • Yes it was, but is of very rare occurrence. – RRUZ Aug 23 '14 at 15:44
  • Your fix is wrong though. Final arg of GetClassName is length in characters. You pass size in bytes. You must pass 256 but pass 512. So your code has a buffer overrun too. But still +1. – David Heffernan Aug 23 '14 at 15:47
  • The problem with the original code was the fact that an api call was made and no error checking performed. I therefore recommend an audit of this entire codebase to check for other calls that omit error checking. The other oddity was that pointless GetMem. I'd also audit for similar spurious heap allocs. – David Heffernan Aug 23 '14 at 16:01
  • Thanks David, I just modify the parameter. about your recommendation I'm always auditing, testing and refactoring the code :) – RRUZ Aug 23 '14 at 16:31
  • Thanks for the fix. But why the exception was not raised by ME? – djsoft Aug 23 '14 at 20:01
  • Got it. The GetLastError after GetClassName returned error code 998, which is "Invalid access to memory location". – djsoft Aug 23 '14 at 20:08
0

That seems to indicate to me that the VCL styles code has a buffer overrun. The madExcept memory manager is succeeding in making that buffer overrun manifest as an exception. In turn the styles code responds by disabling styles.

The next course of action is to run the code under the debugger, with debug DCUs enabled so that you can debug the VCL code. Hopefully the debugger will catch the exception and then highlight the buffer overrun.

If you succeed in identifying the problem you can make a workaround and submit a bug report to QC.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • The problem is - there's no exception. Even with debug DCUs enabled... Could be the exceptions are silenced somehow. Will investigate further. The quality of VCL Styles code is questionable :( – djsoft Aug 23 '14 at 08:38
  • Hard to see how this madExcept feature could be implemented other than with exceptions. Perhaps your ide settings suppress notification in debugger. – David Heffernan Aug 23 '14 at 08:57
  • Yes, madExcept is supposed to produce an exception in case of buffer overrun. All notifications are enabled, this was the first thing I've checked. I've also tested and it catches my test buffer overrun. I'm not sure is this is a VLC bug, or it's something to do with madExcept. Can you reproduce this problem? – djsoft Aug 23 '14 at 09:07
  • I don't have a computer handy. May be worth posting on the madExcept forum. – David Heffernan Aug 23 '14 at 09:21
  • I'm leaving this answer here as it provides a general guide as to how to debug such problems – David Heffernan Aug 24 '14 at 05:28