ResourceManager not threadsafe when case insensitive keys are used

[tl-laurence]

Description

Using resource manager in a high load environment we see errors occurring and strings being read incorrectly. This only happens when the IgnoreCase property is true.

Error message: Corrupt .resources file. Invalid offset '503403335' into data section.

Stack:
at System.Resources.ResourceReader.AllocateStringForNameIndex(Int32 index, Int32& dataOffset) at System.Resources.RuntimeResourceSet.GetObject(String key, Boolean ignoreCase, Boolean isString) at System.Resources.RuntimeResourceSet.GetString(String key, Boolean ignoreCase) at System.Resources.ResourceManager.GetString(String name, CultureInfo culture)

Reproduction Steps

This test fails intermittently but more frequently after a clean rebuild

[TestFixture]
public class ResourceManagerTest
{
    [Test]
    public void GivenCaseInvariantResources_ThenNoErrors()
    {
        Parallel.For(0, 1000, (i) =>
         {
             var resourceMan = new System.Resources.ResourceManager("MyBaseName", typeof(MyAssembly).Assembly);
             resourceMan.IgnoreCase = true;

             Parallel.For(0, 1000, (i) =>
             {
                 var key = "key_that_exists_but_not_in_same_case_as_resources";
                 resourceMan.GetString(key);
             });
         });
    }
}

Expected behavior

The resource should be read without an error as the class is marked as thread safe.

Actual behavior

Error message: Corrupt .resources file. Invalid offset '503403335' into data section.

Stack:
at System.Resources.ResourceReader.AllocateStringForNameIndex(Int32 index, Int32& dataOffset) at System.Resources.RuntimeResourceSet.GetObject(String key, Boolean ignoreCase, Boolean isString) at System.Resources.RuntimeResourceSet.GetString(String key, Boolean ignoreCase) at System.Resources.ResourceManager.GetString(String name, CultureInfo culture)

After the error occurs once resource strings are read incorrectly without and further errors until the application is restarted

Regression?

No response

Known Workarounds

Don't use the IgnoreCase flag

Configuration

.NET 6.0
Errors occurs on:

• Windows 10 Pro x64
• Ubuntu 18.4 x64

Other information

No response

[ghost]

Tagging subscribers to this area: @dotnet/area-system-resources
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Using resource manager in a high load environment we see errors occurring and strings being read incorrectly. This only happens when the IgnoreCase property is true.

Error message: Corrupt .resources file. Invalid offset '503403335' into data section.

Stack:
at System.Resources.ResourceReader.AllocateStringForNameIndex(Int32 index, Int32& dataOffset) at System.Resources.RuntimeResourceSet.GetObject(String key, Boolean ignoreCase, Boolean isString) at System.Resources.RuntimeResourceSet.GetString(String key, Boolean ignoreCase) at System.Resources.ResourceManager.GetString(String name, CultureInfo culture)

Reproduction Steps

This test fails intermittently but more frequently after a clean rebuild

[TestFixture]
    public class ResourceManagerTest
    {
        [Test]
        public void GivenCaseInvariantResources_ThenNoErrors()
        {
            Parallel.For(0, 1000, (i) =>
             {
                 var resourceMan = new System.Resources.ResourceManager("MyBaseName", typeof(MyAssembly).Assembly);
                 resourceMan.IgnoreCase = true;

                 Parallel.For(0, 1000, (i) =>
                 {
                     var key = "key_that_exists_but_not_in_same_case_as_resources";
                     resourceMan.GetString(key);
                 });
             });
        }
    }`

### Expected behavior

The resource should be read without an error as the class is marked as thread safe.

### Actual behavior

Error message: `Corrupt .resources file. Invalid offset '503403335' into data section.`

Stack:
`
  at System.Resources.ResourceReader.AllocateStringForNameIndex(Int32 index, Int32& dataOffset)
   at System.Resources.RuntimeResourceSet.GetObject(String key, Boolean ignoreCase, Boolean isString)
   at System.Resources.RuntimeResourceSet.GetString(String key, Boolean ignoreCase)
   at System.Resources.ResourceManager.GetString(String name, CultureInfo culture)
`

After the error occurs once **resource strings are read incorrectly without and further errors** until the application is restarted

### Regression?

_No response_

### Known Workarounds

Don't use the IgnoreCase flag

### Configuration

.NET 6.0
Errors occurs on:
 - Windows 10 Pro x64
 - Ubuntu 18.4 x64

### Other information

_No response_

<table>
  <tr>
    <th align="left">Author:</th>
    <td>tl-laurence</td>
  </tr>
  <tr>
    <th align="left">Assignees:</th>
    <td>-</td>
  </tr>
  <tr>
    <th align="left">Labels:</th>
    <td>

`area-System.Resources`, `untriaged`

</td>
  </tr>
  <tr>
    <th align="left">Milestone:</th>
    <td>-</td>
  </tr>
</table>
</details>

[steveharter]

Appears to be a bug however we need to verify locally. That method is doc'd as being "thread safe"

Thread Safety
The GetString(String) method is thread safe.

[steveharter]

@tl-laurence is the resource file special in any way (lots of items?) or is it changed at runtime?

Basically wondering how to best repro this.

[tarekgh]

Is this different than #74052?

[ghost]

This issue has been marked needs-author-action and may be missing some important information.

[buyaa-n]

Looks quite similar thanks @tarekgh, @tl-laurence could you try with recent .NET 8 bits where #74052 fixed?

[tl-laurence]

Yes it looks like it could be the same issue as #74052. I will have a go at testing with the suggested version.

@steveharter there is nothing special about the resource files. We have multiple languages configured but can reproduce with a single culture.

It is the IgnoreCase flag and the use of a key that is not in the correct case that causes it from what I have found.

We removed the ignorecase and looked up the keys in a concurrent dictionary instead as a workaround which has stopped the errors.

[danmoseley]

@tl-laurence did you verify it's fixed?

[tl-laurence]

Yes this is fixed in .Net 8