OverflowException: Arithmetic operation resulted in an overflow

jamsharp · May 12, 2025, 11:32am

Hello,

Unfortunately, we experienced an exception when one of our customers dealt with many (and maybe larger) files that they wanted to add to the index.

We got the exception via this event:

pIndex.Events.ErrorOccurred += OnFileAddingErrorOccurred

It was probably triggered during this call, but maybe also during the Optimize() call…

pIndex.Add(...)

The exception:

System.OverflowException: Arithmetic operation resulted in an overflow.\r\n   at \u0008\u0017\u0003.\u0003(Int32 \u0002)\r\n   at \u0008\u0017\u0003.\u0002(String \u0002, Int32 \u0003)\r\n   at \u0002\u001A\u000F.\u0002()\r\n   at \u000F\u0017\u0010.\u0002(\u0002\u0010\u000F \u0002, \u0008\u0010\u000F \u0003)\r\n   at \u0006\u0017\u000F.\u0002\u0016\u000F\u0016\u0005\u0003()\r\n   at \u000F\u0017\u0010.\u0002(\u0003\u0005\u0005 \u0002, \u0003\u000F\u0005 \u0003, \u000F\u0018\u0010 \u0005, \u000E\u0003\u0017 \u0008)\r\n   at \u0003\u001A\u000F.\u0002(Boolean \u0002, Int32 \u0003, \u0003\u0005\u0005 \u0005, \u0003\u000F\u0005 \u0008, \u000F\u0018\u0010 \u0006, OperationType \u000E)

(once again with unescaped charaters):

System.OverflowException: Arithmetic operation resulted in an overflow.
   at .(Int32 )
   at .(String , Int32 )
   at .()
   at .( ,  )
   at .()
   at .( ,  ,  ,  )
   at .(Boolean , Int32 ,  ,  ,  , OperationType )

Some time after that exception, we also got this exception from the same error event. I highly assume that they are related (e.g. one causes the other):

System.ObjectDisposedException: Cannot access a closed file.\r\n   at \u0003\u0005\u0010.\u0002\u0005\u0010\u0016\u0005\u0002(Byte[] \u0002, Int32 \u0003, Int32 \u0005)\r\n   at \u0006\u0018\u000F.\u0002()\r\n   at \u0006\u0018\u000F.\u0005()\r\n   at \u0003\u0016\u000F.\u0002(String \u0002, String \u0003)\r\n   at \u0003\u0016\u000F.\u0002(\u0002\u0005\u0005 \u0002)\r\n   at \u0006\u0017\u000F.\u0002(Document \u0002, IFieldExtractor \u0003, String \u0005, IWordSplitter \u0008)\r\n   at \u0006\u0017\u000F.\u0002(Document \u0002)\r\n   at \u0006\u0017\u000F.\u0002()

(once again with unescaped characters):

System.ObjectDisposedException: Cannot access a closed file.
   at .(Byte[] , Int32 , Int32 )
   at .()
   at .()
   at .(String , String )
   at .( )
   at .(Document , IFieldExtractor , String , IWordSplitter )
   at .(Document )
   at .()

Unfortunately, we don’t know how to reproduce this. Maybe, with large files or many files… We hope that you are able to track the problematic location via the call stack we provided.

I know, I just reported multiple exceptions, but this one is currently the most critical for us…

atir.tahir · May 12, 2025, 6:59pm

@jamsharp
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.

Issue ID(s): SEARCHNET-3516

You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.

jamsharp · July 2, 2025, 1:35pm

Hello, any updates here?

Do you know what causes this?

atir.tahir · July 2, 2025, 6:52pm

@jamsharp

This ticket is still under investigation. We’ll notify you as soon as we’ve any update.

jamsharp · August 14, 2025, 6:58am

Hello,

I think, we all do generally benefit from getting behavior like this one fixed in GroupDocs.Search. But we are wondering: If we bought the paid support, what would be your estimation, how quickly this bug could be fixed and which level of support would we need?

Best regards
jamsharp

atir.tahir · August 14, 2025, 8:00pm

@jamsharp

This issue is still under investigation. As a temporary solution, try adding the following code immediately after creating the index instance.

Index index = new Index(indexFolder, settings, true);
int[] range = Enumerable.Range(0x3300, 0x33FF)
    .Concat(Enumerable.Range(0xFE30, 0xFE4F))
    .Concat(Enumerable.Range(0xF900, 0xFAFF))
    .Concat(Enumerable.Range(0x2F800, 0x2FA1F))
    .Concat(Enumerable.Range(0x2E80, 0x2EFF))
    .Concat(Enumerable.Range(0x31C0, 0x31EF))
    .Concat(Enumerable.Range(0x3000, 0x303F))
    .Concat(Enumerable.Range(0x4E00, 0x9FFF))
    .Concat(Enumerable.Range(0x3400, 0x4DBF))
    .Concat(Enumerable.Range(0x20000, 0x2A6DF))
    .Concat(Enumerable.Range(0x2A700, 0x2B73F))
    .Concat(Enumerable.Range(0x2B740, 0x2B81F))
    .Concat(Enumerable.Range(0x2B820, 0x2CEAF))
    .Concat(Enumerable.Range(0x2CEB0, 0x2EBEF))
    .Concat(Enumerable.Range(0x30000, 0x3134F))
    .Concat(Enumerable.Range(0x31350, 0x323AF))
    .ToArray();
index.Dictionaries.Alphabet.SetRange(range, CharacterType.Separator);

You will get priority support and the issue will be escalated to priority. Please learn more about our paid support.

atir.tahir · August 15, 2025, 11:37am

@jamsharp

As this issue is under investigation, we need some more information:

API version
Target platform (e.g. .NET 8, .NET 4)
Number of documents in the index

jamsharp · August 18, 2025, 7:38am

As far as I know, it was version 25.2.

Target platform: .Net 9

I cannot recall the exact number of documents in the index, sorry. Either, there were 1k to 50k or there were few, because the exception prevented them getting added to the index.

atir.tahir · August 18, 2025, 7:29pm

@jamsharp

Thanks for the details. We’ll notify you in case of any update.

jamsharp · September 15, 2025, 12:17pm

This issue is still under investigation. As a temporary solution, try adding the following code immediately after creating the index instance.

Index index = new Index(indexFolder, settings, true);
int[] range = Enumerable.Range(0x3300, 0x33FF)
    .Concat(Enumerable.Range(0xFE30, 0xFE4F))
    .Concat(Enumerable.Range(0xF900, 0xFAFF))
    .Concat(Enumerable.Range(0x2F800, 0x2FA1F))
    .Concat(Enumerable.Range(0x2E80, 0x2EFF))
    .Concat(Enumerable.Range(0x31C0, 0x31EF))
    .Concat(Enumerable.Range(0x3000, 0x303F))
    .Concat(Enumerable.Range(0x4E00, 0x9FFF))
    .Concat(Enumerable.Range(0x3400, 0x4DBF))
    .Concat(Enumerable.Range(0x20000, 0x2A6DF))
    .Concat(Enumerable.Range(0x2A700, 0x2B73F))
    .Concat(Enumerable.Range(0x2B740, 0x2B81F))
    .Concat(Enumerable.Range(0x2B820, 0x2CEAF))
    .Concat(Enumerable.Range(0x2CEB0, 0x2EBEF))
    .Concat(Enumerable.Range(0x30000, 0x3134F))
    .Concat(Enumerable.Range(0x31350, 0x323AF))
    .ToArray();
index.Dictionaries.Alphabet.SetRange(range, CharacterType.Separator);

Hello @atir.tahir, unfortunately, this workaround does not solve (or prevent) this problem. You already gave me this workaround for a different problem → Indexing corrupted docx file leads to OutOfMemoryException - #14 by atir.tahir, so we had it activated when the problem occurred.

atir.tahir · September 15, 2025, 7:56pm

@jamsharp

We’ll further look into this issue and notify you about the outcomes.

yuriy.mazurchuk · September 24, 2025, 10:04am

Hi @jamsharp!

Can you please check if this problem occurs on the latest version 25.9?
If this issue is still present, can you please share as much information as possible for we can reproduce the issue?

jamsharp · May 11, 2026, 8:30am

Hallo,

Unfortunately, this can still happen in 25.11:

GroupDocs reported an error while adding content to index (we got it via: pIndex.Events.ErrorOccurred):

“System.OverflowException: Arithmetic operation resulted in an overflow.\r\n at \u000F\u0010\u001A.\u0008(Int32 \u0002)\r\n at \u000F\u0010\u001A.\u0002(String \u0002, Int32 \u0008)\r\n at \u0002\u0018\u001B.\u0002()\r\n at \u0008\u0010\u0002.\u0002(\u0002\u0002\u001B \u0002, \u0006\u0002\u001B \u0008)\r\n at \u0003\u0017\u001B.\u000E\u0010\u001B\u0003\u0016\u0002(List1 \u0002, List1 \u0008)\r\n at \u0002\u0017\u001B.\u000E\u0010\u001B\u0003\u0016\u0002(List1 \u0002, List1 \u0008)\r\n at \u0008\u001B\u001B.\u0002(List1 \u0002, List1 \u0008)\r\n at \u0003\u0010\u001B.\u0002\u001B\u001B\u0003\u0016\u0008()\r\n at \u0008\u0010\u0002.\u0002(\u000E\u0015\u0003 \u0002, \u000F\u0016\u0003 \u0008, \u0008\u0017\u0002 \u0005, \u0005\u0019\u0017 \u0006)\r\n at \u0008\u0018\u001B.\u0002(Boolean \u0002, Int32 \u0008, \u000E\u0015\u0003 \u0005, \u000F\u0016\u0003 \u0006, \u0008\u0017\u0002 \u0003, OperationType \u000E)”

yuriy.mazurchuk · May 11, 2026, 7:46pm

Hello @jamsharp!

Let us investigate this issue again and get back to you once we have figured it out.
Please share if you were able to reproduce this issue on the same files provided before, or were there some other files?

jamsharp · May 12, 2026, 9:43am

Please share if you were able to reproduce this issue on the same files provided before
As far as I know, we were not able to reproduce this again with our files.

or were there some other files?
Yes. this happened with other files on a PC of our customers. Currently, we don’t know which files exactly caused that and are not sure whether we will get them. We hope that the callstack can help finding the source of the problem.

yuriy.mazurchuk · May 13, 2026, 12:51pm

Hi, @jamsharp!

So far, it seems the problem we faced is related to the 2 GB memory limit for the array variable. This leads su to internal framework reworking.
Potentially, there are a few possibilities for avoiding this on your side. The specific solution depends on the target framework and application type you are using.

Can you please try to set up the configuration **gcAllowVeryLargeObjects**
For the .Core project you may try in scproj file

<PropertyGroup>
  <RuntimeHostConfigurationOption Include="System.GC.AllowVeryLargeObjects" Value="true" />
</PropertyGroup>

After build with .net NNN, check bin/Debug/netNNN/YourApp.runtimeconfig.json and you should see:

{
  "runtimeOptions": {
    "configProperties": {
      "System.GC.AllowVeryLargeObjects": true
    }
  }
}

Alternative — runtimeconfig.template.json next to your .csproj:

{
  "configProperties": {
    "System.GC.AllowVeryLargeObjects": true
  }
}

Hope this could help you until we resolve the issue on our side and deploy the new version.
Thank you!

jamsharp · May 19, 2026, 2:49pm

Thanks. I will try out the workaround.

jamsharp · May 22, 2026, 2:47pm

Hello,

We evaluated your quickfix/workaround suggestion, but concluded that that will probably not work.

These are AI thoughs about this topic:

gcAllowVeryLargeObjects only affects array length limits, not integer arithmetic boundaries.
A System.OverflowException thrown inside arithmetic code cannot be fixed by changing GC settings.
The stack trace shows obfuscated method names, but the exception is thrown during an Int32 arithmetic operation, not during memory allocation.
If an overflow happens during array indexing (index * elementSize, offset calculations, etc.), enabling very large arrays may change internal code paths and could indirectly avoid the overflow, but only if the library authors accessed arrays incorrectly.

Also:

The 2‑GB LOH array limit is real in .NET Framework, but no longer applies in .NET Core / .NET 5+, where arrays can exceed 2 GB even without AllowVeryLargeObjects = true.

We are using .Net 10, so setting the runtime setting should not change anything, unfortunately.

Can you estimate when this will be fixed? This is important for us, because a different customer of us experienced this, too.
When the arithmetic overflow happens during index.Add, future index.Add operations tend to not work because of a System.ObjectDisposedException:

System.OverflowException: Arithmetic operation resulted in an overflow.\r\n   at \u000F\u0010\u001A.\u0002(String \u0002, Int32 \u0008)\r\n   at \u0002\u0018\u001B.\u0002()\r\n   at \u0008\u0010\u0002.\u0002(\u0002\u0002\u001B \u0002, \u0006\u0002\u001B \u0008)\r\n   at \u0003\u0017\u001B.\u0005()\r\n   at \u0008\u001B\u001B.\u0002(\u0003\u0015\u0003 \u0002)\r\n   at \u0003\u0010\u001B.\u0002(Document \u0002, IFieldExtractor \u0008, String \u0005, IWordSplitter \u0006)\r\n   at \u0003\u0010\u001B.\u0002(Document \u0002)\r\n   at \u0003\u0010\u001B.\u0002()

System.ObjectDisposedException: Cannot access a closed file.\r\n   at \u0008\u0015\u0002.\u0002\u0015\u0002\u0003\u0016\u0002(Byte[] \u0002, Int32 \u0008, Int32 \u0005)\r\n   at \u0003\u0017\u001B.\u0002()\r\n   at \u0003\u0017\u001B.\u0005()\r\n   at \u0008\u001B\u001B.\u0002(\u0003\u0015\u0003 \u0002)\r\n   at \u0003\u0010\u001B.\u0002(Document \u0002, IFieldExtractor \u0008, String \u0005, IWordSplitter \u0006)\r\n   at \u0003\u0010\u001B.\u0002(Document \u0002)\r\n   at \u0003\u0010\u001B.\u0002()