Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions src/code/graph.c
Original file line number Diff line number Diff line change
Expand Up @@ -141,6 +141,13 @@ void Graph_InitTHGA(GraphicsContext* gfxCtx) {
gfxCtx->overlayBuffer = pool->overlayBuffer;
gfxCtx->workBuffer = pool->workBuffer;

//! @bug fbIdx is a signed integer that can overflow into the negatives. When compiled with a C99+ compiler or IDO,
//! the remainder operator will yield -1 for odd negative values of fbIdx.
//! This results in an out of bounds array access in SysCfb_GetFbPtr due to the negative index value,
//! which will crash the game.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest something like

Suggested change
//! which will crash the game.
//! which will most likely read an invalid pointer (a NULL pointer in the case of all matching versions) and crash the game when trying to render to that "framebuffer".

to not make it sound like it's the OoB access which directly crashes the game

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yea this is why i didn't bother stating that it crashes the game. It should be pretty obvious that fetching the color framebuffer pointer from an unintended memory address would lead to devastating consequences.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

may as well not leave things up to interpretation though, right

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

bump

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To me, there isn't a good reason to explain what happens past the OOBs read. When you go beyond that point, there are so many different possible outcomes to consider, none of which are consistent, and none of which are important if your goal is to fix the bug.

Where I think I could be clearer is I could state that the oobs read happens when trying to retrieve the next framebuffer pointer. I think knowing that the color framebuffer pointer is being set to a garbage value is enough on it's own to hint that bad things are going to happen soon.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont see why we have to "hint" at anything. Its perfectly okay to say what will probably happen.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I don't know what would "probably" happen once the framebuffer ptr is assigned to garbage data.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what dragorn wrote is fine.

//!
//! In practice, this isn't an issue. In the worst case scenario with the game operating at a consistent 60 FPS,
//! it would take approximately 414.25 days of continuous operation for fbIdx to overflow.
gfxCtx->curFrameBuffer = SysCfb_GetFbPtr(gfxCtx->fbIdx % 2);
gfxCtx->unk_014 = 0;
}
Expand Down