UPD: replaced 2.30 → 2.29 in the description. Per my colleague's test, 2.29 works too.
** Description changed: 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. + 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.30 read() only happens for the *last + 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()`. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1861776 Title: fseek(…, …, SEEK_SET) causes reading over the skipped range To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1861776/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
