starred/sharpcompress
1
0
Fork 0
mirror of https://github.com/adamhathcock/sharpcompress.git synced 2026-02-03 21:23:38 +00:00
Code Issues 975 Packages Projects Releases 20 Wiki Activity

Stack Overflow due to large stack allocations #705

New Issue
Closed
opened 2026-01-29 22:16:13 +00:00 by claunia · 1 comment
claunia commented 2026-01-29 22:16:13 +00:00
Owner
Copy Link

Originally created by @RawScape on GitHub (Oct 22, 2025).

I experienced stack overflows in my program accompanied by a dump-file.
Analyzing this dump lead me to SharpCompress.
Specifically "SharpCompress/Compressors/Rar/UnpackV1/Unpack.cs" where larger chunks of memory are allocated on the stack.
Since I decompress several Archives in parallel this leads to a stack overflow.

I replaced

Span<byte> VMCode = stackalloc byte[VMCodeSize];
for (var I = 0; I < VMCodeSize; I++)
{
    if (Inp.Overflow(3))
    {
        return (false);
    }
    VMCode[I] = (byte)(Inp.GetBits() >> 8);
    Inp.AddBits(8);
}

// VM.Prepare(&VMCode[0],VMCodeSize,&Filter->Prg);
rarVM.prepare(VMCode, VMCodeSize, Filter.Program);

with

byte[] VMCode = ArrayPool<byte>.Shared.Rent(VMCodeSize);
try
{
    for (var I = 0; I < VMCodeSize; I++)
    {
        if (Inp.Overflow(3))
        {
            return (false);
        }
        VMCode[I] = (byte)(Inp.GetBits() >> 8);
        Inp.AddBits(8);
    }
    rarVM.prepare(VMCode, VMCodeSize, Filter.Program);
}
finally
{
    ArrayPool<byte>.Shared.Return(VMCode);
}

and this solved my problem.

I can see other similar large stack allocations in the project.
But this is the one that caused my crashes.

Originally created by @RawScape on GitHub (Oct 22, 2025). I experienced stack overflows in my program accompanied by a dump-file. Analyzing this dump lead me to SharpCompress. Specifically "SharpCompress/Compressors/Rar/UnpackV1/Unpack.cs" where larger chunks of memory are allocated on the stack. Since I decompress several Archives in parallel this leads to a stack overflow. I replaced ``` Span<byte> VMCode = stackalloc byte[VMCodeSize]; for (var I = 0; I < VMCodeSize; I++) { if (Inp.Overflow(3)) { return (false); } VMCode[I] = (byte)(Inp.GetBits() >> 8); Inp.AddBits(8); } // VM.Prepare(&VMCode[0],VMCodeSize,&Filter->Prg); rarVM.prepare(VMCode, VMCodeSize, Filter.Program); ``` with ``` byte[] VMCode = ArrayPool<byte>.Shared.Rent(VMCodeSize); try { for (var I = 0; I < VMCodeSize; I++) { if (Inp.Overflow(3)) { return (false); } VMCode[I] = (byte)(Inp.GetBits() >> 8); Inp.AddBits(8); } rarVM.prepare(VMCode, VMCodeSize, Filter.Program); } finally { ArrayPool<byte>.Shared.Return(VMCode); } ``` and this solved my problem. I can see other similar large stack allocations in the project. But this is the one that caused my crashes.
claunia commented 2026-01-29 22:16:13 +00:00
Author
Owner
Copy Link

@adamhathcock commented on GitHub (Oct 22, 2025):

Thanks!

I fixed the reported thing here https://github.com/adamhathcock/sharpcompress/pull/966

I took a brief look to see there's any other potentially large dynamic stackallocs and I don't see any. Hopefully this fixes it.

@adamhathcock commented on GitHub (Oct 22, 2025): Thanks! I fixed the reported thing here https://github.com/adamhathcock/sharpcompress/pull/966 I took a brief look to see there's any other potentially large dynamic stackallocs and I don't see any. Hopefully this fixes it.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
duplicate
enhancement
feedback requested
not bug
pull-request
Mirrored from GitHub Pull Request
 question
up for grabs
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/sharpcompress#705
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?