tree ec2d0cfbfa867dba6870c58484125d47a9d32d42
parent 550087f185e7f53a0053b447d2167edb59b5a8c5
author Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> 1539769470 +0200
committer Niraj Modi <niraj.modi@in.ibm.com> 1540204394 -0400

Bug 539796 - [Win32] Crash in ScriptStringOut

This fixes the problem.
Signature for ScriptStringAnalyse changed to keep the native string.

Previously, JNI wrapper for ScriptStringAnalyse deallocated temporary
native string upon exit, causing ScriptStringOut to read already-freed memory.
Depending on circumstances that will
1) Read memory that is still intact, making impression that it works fine
2) Read memory overwritten by new owner
3) Crash if entire virtual page was deallocated by Windows

In the original fix for Bug 239477, it was incorrectly assumed that
Uniscribe libraries crash. The true problem is that when a buffer is
big enough (such as 16665 used in test snippet), Windows will most
likely deallocate virtual pages along with the heap block, and subsequent
read from such page will guarantee a crash. With buffer of just 2 characters
the problem is still there, but most often the memory will be intact for
short while after deallocation, because virtual page containing deallocated
block is still occupied with other heap blocks.

Workaround from Bug 239477, that is estimating font by just 2 characters,
has its own side effects. It will be addressed in future patches.

Easily reproducible with Application Verifier configured for Basics/Heaps,
because Application Verifier reduces the chances to access freed memory
to almost zero.

Code snippet that reproduces the problem:
	final Display display = new Display();
	TextLayout layout = new TextLayout(display);
	layout.setText("\u0001");
	layout.getBounds();

Change-Id: Ibc5e15b173beca54b2ed73cdcb1bc9eb40d4187d
Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com>