2.3.4 throwing System.AccessViolationException

[funex]

Randomly I get the following exception:

Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.AccessViolationException
at Icu.NativeMethods.ubrk_next(IntPtr)
at Icu.RuleBasedBreakIterator.SetText(System.String)

To Reproduce

Cannot reproduce it locally.
This has been an issue on earlier versions as discussed at #56

Environment

• OS: Windows Server 2012R2 64 bit
• icu.net 2.3.4 with Icu4c.Win.Full.Lib 56.1.0
• Framework Version: v4.0.30319

[funex]

Adding wrapper.Cleanup() seemed to have improved things, I'll run some more tests and eventually/hopfeully close this issue.

[funex]

This issue still occurs, wrapper.Init() and Cleanup() didn't help.

I'm seeing the same exception in the same location. I'm trying to create a set of steps to reproduce, but finding it difficult.

OS: Windows 10 Enterprise
icu.net: 2.5.1 with Icu4cWin.Full.Lib v59.1.15
Framework Version: v4.0.30319

[funex]

I'm seeing the same exception in the same location. I'm trying to create a set of steps to reproduce, but finding it difficult.

OS: Windows 10 Enterprise
icu.net: 2.5.1 with Icu4cWin.Full.Lib v59.1.15
Framework Version: v4.0.30319

Same thing with me, I haven't figured out how to reproduce it.

Just looking at the code, I think I know what might be going on.

From here: "As an optimization when either string type is marshaled by value (such as a Unicode character string), the marshaler passes the callee a direct pointer to managed strings in the internal Unicode buffer instead of copying it to a new buffer."

In RuleBreakerIterator.cs, SetText method lines 410 - 466:

• Calls ubrk_setText(..) // passing pointer to the string internal buffer
• Then calls ubrk_first(..) and ubrk_next(...) until done.

It's possible that garbage collection happens in the managed code and relocates the Text string -- which would invalidate the pointer being passed (and held) by ubrk_setText(...) and would cause problems for subsequent calls to ubrk_next(...). (Unless icu4c is making a copy of the string -- which would be inefficient).

I'm using the Nuget version of icu.net and not building the project directly. Anyone who's building directly should be able to test my assertions.

UPDATE:
I was able to validate that this is indeed the case and I have a fix. I will try to generate a pull-request by tomorrow, but the basic approach is to lock down the Text:

unsafe {
   fixed (char * p = _text ) {
      NativeMethods.ubrk_setText(_breakIterator, Text, Text.Length, out err);
     ...
   }
}

Note: this requires compiling with /unsafe flag

[ermshiperete]

This should be fixed in 2.5.3.