| 2020-02-05 08:27:30 |
Konstantin |
description |
When fseek is called, it calls in turn 1. lseek(), and 2. read(). In glibc 2.30 (maybe earlier) read() is only called for the last block. However in glibc 2.27 Ubuntu 18.04 is using, the read happens over the whole skipped range, which may cause a hang of an app that tries to skip too big range.
There's is a related report: https://sourceware.org/bugzilla/show_bug.cgi?id=25497 Note, per comments, in at least glibc 2.30 read() only happens for the *last block*. This means there was some fix for fseek() to not read over everything it skipped, which Ubuntu didn't backport to older glibc it's using.
# Steps to reproduce
In command below, replace `/dev/sda` if necessary with a device that is at least 2 GB in size.
Run `sudo hexdump -C /dev/sda -s 0x80000000 -n 1`. This command uses `hexdump` to print content of a disk at a large offset.
## Expected
The command returns immediately with a print
## Actual
The command hangs with high CPU load. If you use `strace hexdump …`, you'll see there a bunch of reads happens. These reads arise from glibc 2.27 implementation of `fseek()`. |
When fseek is called, it calls in turn 1. lseek(), and 2. read(). In glibc 2.29 (maybe earlier) read() is only called for the last block. However in glibc 2.27 Ubuntu 18.04 is using, the read happens over the whole skipped range, which may cause a hang of an app that tries to skip too big range.
There's is a related report: https://sourceware.org/bugzilla/show_bug.cgi?id=25497 Note, per comments, in at least glibc 2.29 read() only happens for the *last block*. This means there was some fix for fseek() to not read over everything it skipped, which Ubuntu didn't backport to older glibc it's using.
# Steps to reproduce
In command below, replace `/dev/sda` if necessary with a device that is at least 2 GB in size.
Run `sudo hexdump -C /dev/sda -s 0x80000000 -n 1`. This command uses `hexdump` to print content of a disk at a large offset.
## Expected
The command returns immediately with a print
## Actual
The command hangs with high CPU load. If you use `strace hexdump …`, you'll see there a bunch of reads happens. These reads arise from glibc 2.27 implementation of `fseek()`. |
|
