** Description changed: ## Summary Opening a folder that contains several large MP4 files (1-3 GB each) in Gwenview 25.12.3 on Ubuntu 26.04 freezes the UI (grey image, unresponsive) and can crash the application when browsing directories. The cause is libexiv2 0.28.8, which loads the entire MP4 file into memory when reading its metadata (peak memory equals file size). Gwenview 25.12.3 requests metadata for every video in the folder on the main thread, so it triggers multi-GB allocations one after another. The Flatpak build of Gwenview 26.04.3 does not show the problem with the same folder and the same libexiv2 0.28.8, so a Gwenview-side change between these versions avoids it. ## Environment - Ubuntu 26.04 (resolute), amd64, Wayland - gwenview 4:25.12.3-0ubuntu1 (Qt 6.10.2) - libexiv2-28 0.28.8+dfsg-1 - exiv2 CLI 0.28.8 (installed for testing) - RAM: 15 GiB total, 15 GiB swap (swap unused; the freeze occurs without - memory pressure) + memory pressure) - GPU: Intel Iris Xe (TigerLake-LP GT2) ## Steps to reproduce 1. Put several large MP4 files (1-3 GB each) in one folder. 2. Open that folder in Gwenview, either with no image selected or by - browsing into it. + browsing into it. 3. Gwenview freezes while it scans the folder. Reproduction without Gwenview: - /usr/bin/time -f '%M KB peak, %e s' exiv2 -pa -- video_01.mp4 + /usr/bin/time -f '%M KB peak, %e s' exiv2 -pa -- video_01.mp4 Untested suggestion for generating a test file: - ffmpeg -f lavfi -i testsrc=duration=600:size=1920x1080:rate=30 \ - -c:v libx264 -b:v 20M test.mp4 + ffmpeg -f lavfi -i testsrc=duration=600:size=1920x1080:rate=30 \ + -c:v libx264 -b:v 20M test.mp4 ## Expected result Gwenview stays responsive when opening a folder with large videos. Metadata extraction from an MP4 reads only the container headers and uses a small, roughly constant amount of memory regardless of file size. ## Actual result Peak memory of exiv2 tracks file size almost exactly: | File | File size (KB) | Peak RSS (KB) | Time (s) | |----------|----------------|---------------|----------| | video_01 | 3,324,170 | 3,299,956 | 1.16 | | video_02 | 2,553,935 | 2,511,084 | 0.93 | | video_03 | 2,205,256 | 2,208,584 | 0.75 | | video_04 | 1,997,923 | 2,000,680 | 0.67 | | video_05 | 2,012,646 | 1,961,120 | 0.74 | | video_06 | 1,908,928 | 1,857,536 | 0.70 | | video_07 | 1,770,441 | 1,773,996 | 0.60 | | video_08 | 1,765,454 | 1,768,900 | 0.59 | | video_09 | 1,368,436 | 1,372,112 | 0.47 | | video_10 | 1,262,371 | 1,267,056 | 0.43 | Small files (e.g. a 475 KB PNG, 530x762) use about 1 MB, so this is not a general exiv2 problem, only large container files. ## Evidence from Gwenview `strace -f -k -e trace=mmap,munmap gwenview` shows repeated anonymous mmaps of 1.2-2.5 GB (e.g. 1288937472, 1893617664, 1999626240, 1807974400, 2562908160 bytes), each followed by a matching munmap. Call stack of every large allocation: - operator new (libstdc++) - libexiv2.so.0.28.8 - libexiv2.so.0.28.8 - libexiv2.so.0.28.8 - libgwenviewlib.so.4.97.0 - libgwenviewlib.so.4.97.0 - libQt6Core.so.6.10.2 ... + operator new (libstdc++) + libexiv2.so.0.28.8 + libexiv2.so.0.28.8 + libexiv2.so.0.28.8 + libgwenviewlib.so.4.97.0 + libgwenviewlib.so.4.97.0 + libQt6Core.so.6.10.2 ... The allocations occur on the main thread (munmap alone takes 50-110 ms each). A clean config (Gwenview files removed from ~/.config and ~/.local/share) makes no difference. The freeze occurs even when no image is open, as soon as the folder is scanned. Browsing directories inside Gwenview can also crash it. ## Additional findings - Bisecting the folder contents: the problem disappears when the MP4 files - are removed. + are removed. - The Flatpak build of Gwenview 26.04.3 (runtime org.kde.Platform 6.10) does - not show the problem with the same folder, even though it bundles the same - libexiv2 0.28.8 as the Ubuntu package. So the behaviour was changed or - fixed in Gwenview between 25.12.3 and 26.04.3. The specific upstream change - has not been identified. + not show the problem with the same folder, even though it bundles the same + libexiv2 0.28.8 as the Ubuntu package. So the behaviour was changed or + fixed in Gwenview between 25.12.3 and 26.04.3. The specific upstream change + has not been identified. - Gwenview on Ubuntu 24.04 on the same hardware did not show this problem. - Not tested: whether other large container formats (MKV, MOV) behave the - same, and whether this is a regression within the exiv2 0.28 series. + same, and whether this is a regression within the exiv2 0.28 series. - Crash when browsing directories: observed, no crash report captured. ## Impact Gwenview is unusable (long freezes, crashes) in any folder containing large videos, such as Downloads. On systems with less RAM this can cause swapping or an out-of-memory kill. Any application that calls exiv2 on large videos is likely affected. ## Notes libexiv2 0.28.8 reads the whole MP4 into memory to extract metadata (confirmed with the exiv2 CLI). Gwenview 25.12.3 requests metadata for videos in the folder on the main thread, which triggers it. Gwenview 26.04.3 does not show the problem with the same exiv2 version, so a Gwenview-side change avoids it. Request: update gwenview to 26.04.x in Ubuntu 26.04, or backport the relevant fix. The exiv2 whole-file read is worth a separate upstream report. Workaround: use the Flatpak build (org.kde.gwenview) or keep large videos out of folders browsed with Gwenview. - Filing: run ubuntu-bug gwenview and paste this in. If you also report to github.com/Exiv2/exiv2, reuse the “Actual result” table and the CLI reproduction line, and link the two bugs to each other. - Attachments: if you attach the full strace output, search it for filenames first (grep -i '\.mp4' /tmp/gw*.txt). The mmap-only trace shouldn’t contain any, but check. - Crash report: if Gwenview crashes again, coredumpctl list may show an entry. A stack trace from coredumpctl info gwenview would strengthen the report, and you could then replace the “no crash report captured” line. + PS: bug found and filed with help of Sonnet 5.5 ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: exiv2 0.28.8+dfsg-1 ProcVersionSignature: Ubuntu 7.0.0-38.38-generic 7.0.14 Uname: Linux 7.0.0-38-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Sun Oct 11 20:18:08 2026 SourcePackage: exiv2 UpgradeStatus: Upgraded to resolute on 2026-09-29 (12 days ago) modified.conffile..etc.default.apport: - # set this to 0 to disable apport, or to 1 to enable it - # you can temporarily override this with - # sudo service apport start force_start=1 - enabled=0 + # set this to 0 to disable apport, or to 1 to enable it + # you can temporarily override this with + # sudo service apport start force_start=1 + enabled=0 mtime.conffile..etc.default.apport: 2023-09-28T11:44:55.503720
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2170505 Title: gwenview 25.12.3 freezes/crashes in folders with large MP4 files (reads whole video via exiv2 0.28.8); not reproducible with 26.04.3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gwenview/+bug/2170505/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
