After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 738956 - Potential offset overflow on 32-bit
Potential offset overflow on 32-bit
Status: RESOLVED OBSOLETE
Product: vte
Classification: Core
Component: general
0.38.x
Other Linux
: Normal minor
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-10-21 19:19 UTC by Egmont Koblinger
Modified: 2021-06-10 14:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Egmont Koblinger 2014-10-21 19:19:06 UTC 
VTE uses gsize for the ever-increasing logical byte offset in the ring/stream/etc. This overflows after printing ~25M lines of 80 characters which is not an unreasonably extreme scenario, vte can process this much data in about 15 minutes. Buggy behavior is bound to happen (although I haven't tested) both in memory, and in the scrollback file with infinite scrollback.

We should #define _FILE_OFFSET_BITS 64, s/gsize/off_t, s/fseek/fseeko, maybe some compiletime/runtime assertions on these sizes -- what else?

Preferably not just for byte offsets but also for line offsets (insert_delta/scroll_delta etc.).
Comment 1 Behdad Esfahbod 2014-10-21 19:39:02 UTC 
Can we do it without API implications?  I fully support an easy define somewhere!
Comment 2 Egmont Koblinger 2014-10-21 20:08:58 UTC 
s/gsize/off_t should be selective (not a blind #define or search-n-replace, but only where the semantics is file offset). #define _FILE_OFFSET_BITS 64 and s/fseek/fseeko are probably easy bits, although I don't know how they'd influence non-Linux systems.

What API do you think of? I think we don't rely on glib for such file operations, only on glibc, where apparently the magic is hidden for us (probably fwrite() and friends map to a different call if _FILE_OFFSET_BITS==64, not sure how else it could take varying width arguments, but that's not our business, it's already done).

I don't think vte's API would need to be changed.

I'm not sure about any of these, though :)

IMO the tough part is finding a 32-bit test machine (I don't have any) or bringing up a VM or figuring out how to build against 32-bit libs (and hoping that's the same), then coming up with a reproducible test case, maybe saving that 15 minutes every time by manually seeking to almost 2^31 or 2^32 (I'm not even sure which)...
Comment 3 Egmont Koblinger 2014-10-21 20:16:04 UTC 
BTW I'm not even sure this bug is worth addressing. Do we know how many computers that run gnome-terminal are 32 vs. 64-bit and what's the trend? Are 32-bit computer going to die out in a few years, or will they live long (in tablets, OLPC etc.)? This bug is likely hit by power users only, I doubt many of them are still stuck with 32-bits. I don't know.
Comment 4 Behdad Esfahbod 2014-10-21 22:11:04 UTC 
Yes, I think since we got away with it till now, we might as well ignore it.
Comment 5 GNOME Infrastructure Team 2021-06-10 14:57:45 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/2140.