AV with a big font

x_ginger · Post by **x_ginger** » Thu Mar 26, 2015 1:44 pm

If somebody types a letter, then sets a font size of the letter to 99 or more, then chooses the font named "Flut Saus" (http://www.dafont.com/flutsaus.font), there will be an AV:
Project .... raised exception class EAccessViolation with message 'Access violation at address 0113EBB4 in module '...'. Read of address 4A9B1ED0'.
It is because of uninitialized variable Result in the function MaxFitSafe. The value of the variable is bigger than the length of the word.
As I can see, Result should be initialized here:

Code: Select all

    if (rvpaoNoWrap in pi.Options) or not Params.AllowWordWrap then
      Result := MaxLen
    else begin
      RVU_GetTextExtentExPointPC(Params.FormatCanvas, SourceStrPtr, MaxLen,
        RVConvertToFormatCanvas(SpaceTillTheEndOfLine, Params.UseFormatCanvas),
        Result, nil, li.ItemOptions, sz, RVStyle.GraphicInterface);

But it does not happen, because of function Windows.GetTextExtentExPointW. It returns False and does not calculate any other values.
The font Flut Saus is not only one that makes this error.
TRVWinGraphicInterface.GetTextExtentExPoint_W is a procedure so we cant check its result.

What can we do to prevent this error?

Post by **Sergey Tkachenko** » Thu Mar 26, 2015 2:15 pm

I am afraid it cannot be fixed in the current release version, because the alternative maxfit calculation using GetTextExtentExPoint does not work good for ScaleRichView - it fails for wide strings.

However, in the current beta version we improved this method, so it can be used in ScaleRichView too. I'll see how we can fix this bug.

MarkElder · Post by **MarkElder** » Thu Apr 09, 2015 5:57 pm

I am running into the same error. However in my case I don't have a font that large. I have a customer who just purchased a new computer that is getting this on all our reports.

We are performing a custom mail merge and displaying the results in a Scale Rich View. We are getting the AV on line 1895 in MaxFitSave where result is used as a index in the PRVWordArray.

What I can't figure out is why GetTextExtentExPoint is failing in the first place. If I can figure that out I can fix his machine. Since the code does not call GetLastError when GetTextExtentExPoint fails I stuck. Any ideas on what can cause the call to fail for a document that works fine on other machines?

Post by **Sergey Tkachenko** » Fri Apr 10, 2015 6:28 am

Are you sure that this is AV, not a range check error?
For correct working, TRichView must be compiled without range checking.
In the new version of TRichView, it is by default, RVNORANGECHECK is defined in RV_Defs.inc

MarkElder · Post by **MarkElder** » Fri Apr 10, 2015 2:35 pm

Yes I'm sure it's an AV

We did track this down to an install issue. We use the Arial Narrow font in our templates. The user had installed Office (which includes that font) but had not yet rebooted their computer.

The font lookup normally just falls back to Arial if the Narrow version cannot be found. It seems like the Office install put things in a weird state where the font was there but could not be used by GetTextExtentExPoint. That's my theory anyway. We rebooted the computer and it started working again.

Post by **Sergey Tkachenko** » Wed Jul 01, 2015 8:06 pm

I cannot reproduce this problem with flutSaus font (I tried both OTF and TTF versions, with font sizes up to 200pt).
However, I added a check on results of GetTextExtentExPoint. If it fails, the component will try using GetTextExtentPoint32. If it fails, the component assumes zero size for the text. No AV should occur any more.

This change will be included in the next update.