Skip to content

Crash on tooltip hovering: snprintf buffer overflow fix#350

Open
caco3 wants to merge 1 commit intozevv:v1.5.0-rc2from
caco3:fix-gui-crash-on-hovering
Open

Crash on tooltip hovering: snprintf buffer overflow fix#350
caco3 wants to merge 1 commit intozevv:v1.5.0-rc2from
caco3:fix-gui-crash-on-hovering

Conversation

@caco3
Copy link
Copy Markdown

@caco3 caco3 commented Jan 23, 2026

The gen_tooltip function now properly tracks the remaining buffer space:

  • Added bounds checking with if(r > 0 && r < l)
  • Decrements remaining buffer size l -= r when advancing pointer p
  • Prevents writing past the end of the tooltip_msg buffer

This should resolve the GUI crash when hovering over the graph.

The gen_tooltip function now properly tracks the remaining buffer space:

Added bounds checking with if(r > 0 && r < l)
Decrements remaining buffer size l -= r when advancing pointer p
Prevents writing past the end of the tooltip_msg buffer
This should resolve the GUI crash when hovering over the graph.
@caco3 caco3 changed the title ✅ snprintf buffer overflow fix reapplied Crash on tooltip hovering: snprintf buffer overflow fix Jan 24, 2026
@caco3 caco3 mentioned this pull request Apr 1, 2026
if(name) {
p += snprintf(p, l, "name: %s\n", name);
int r = snprintf(p, l, "name: %s\n", name);
if(r > 0 && r < l) {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

What values meet this criteria?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

The condition guards against two distinct snprintf failure/edge cases:

  • r > 0snprintf returns a negative value on encoding errors, and 0 if nothing was written. Advancing p or decrementing l in those cases would be wrong.

  • r < lsnprintf returns the number of characters it would have written if the buffer were large enough, regardless of truncation. So if r >= l, the output was truncated: only l-1 bytes were actually written, but r is larger than l. Advancing p by r would jump past the end of the buffer.

The combined check r > 0 && r < l means: "snprintf succeeded and the output fit entirely in the remaining buffer" — only then is it safe to advance p by exactly r and subtract r from l.

One subtle implication: if truncation occurs (i.e., r >= l), the pointer p and size l are not updated, so subsequent writes still start at the same (now null-terminated) position. This effectively silently drops the truncated content rather than writing garbage or crashing.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

But an int can’t be both >0 and <1

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

r < l

It is not a number, its the letter L!

And don't complain about this, it was not me who introduced the l variable 😄

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

So it is! Sorry for the noise

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

No problem!
It is better to be to too cautious than introducing new bugs.

@l8gravely
Copy link
Copy Markdown
Collaborator

l8gravely commented Apr 5, 2026 via email

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.

3 participants