Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Oom alloc #463

Open
wants to merge 18 commits into
base: master
Choose a base branch
from
Open

Oom alloc #463

wants to merge 18 commits into from

Conversation

sftse
Copy link
Contributor

@sftse sftse commented Aug 29, 2024

Was it intentional that fn from_sparse assumes cells are in (row, col) order? This test example demonstrates this is not always the case and OOM allocates due to an overflow.

Based on #462 restructured history

@sftse sftse mentioned this pull request Aug 30, 2024
@sftse
Copy link
Contributor Author

sftse commented Aug 30, 2024

Added another example that OOMs, hasn't been fixed yet, I'm working around it for my usecase by using unstable set_alloc_error_hook

@tafia
Copy link
Owner

tafia commented Sep 16, 2024

Thanks!
Tiny comment just to help future debugging if needed.

@sftse
Copy link
Contributor Author

sftse commented Sep 16, 2024

Do you mean a comment explaining the last OOM file that was added?

@sftse sftse force-pushed the oom-alloc branch 2 times, most recently from 17fc324 to 1ffc325 Compare October 27, 2024 13:24
@sftse
Copy link
Contributor Author

sftse commented Oct 27, 2024

I've added a FIXME to the function call that OOMs, if this was not what was meant please advise further.
This is ready to merge imho.

@sftse
Copy link
Contributor Author

sftse commented Oct 28, 2024

Curious whether you know anything about the unknown record types as mentioned in #462.
The commit history was starting to look complex, so I folded it into this PR.

sftse added 18 commits October 30, 2024 11:22
When reading a PtgStr 2.5.198.89 the cch byte of ShortXLUnicodeString
indicates the number of characters in the string. The error here is twofold:

1. The byte buffer holding the string characters in prematurely truncated
before calling fn read_unicode_string_no_cch() based on cch, although
the correct length in bytes can only be known inside fn read_unicode..()
after checking the fHighByte flag. The fix is to not truncate the buffer at all
pass it in its entirety so that fn read_unicode..() may decide how many
bytes to read.

2. The second error then advances the offset into the buffer based on this
erroneous length, which later leads to crashes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants