diff options
Diffstat (limited to 'results/classifier/gemma3:27b/syscall/1734')
| -rw-r--r-- | results/classifier/gemma3:27b/syscall/1734 | 19 |
1 files changed, 19 insertions, 0 deletions
diff --git a/results/classifier/gemma3:27b/syscall/1734 b/results/classifier/gemma3:27b/syscall/1734 new file mode 100644 index 00000000..93a5449a --- /dev/null +++ b/results/classifier/gemma3:27b/syscall/1734 @@ -0,0 +1,19 @@ + + + +mmap-ing more than 1GB of files fails on v8.0 of QEMU, but works on older version +Description of problem: +Trying to run an application using QEMU user mode for an ARM binary. My host system is Ubuntu 22.04 based. The v6.2 from Ubuntu repos is able to mmap files that contain more than 1GB of address space, but version 8.0 that I compiled will not. + +I created a repo with a readme, and a simple application that you can use to demonstrate the problem: +https://github.com/mwales/qemu_mmap_test + +Example application simply takes a list of files, mmaps the entire file into memory, and then computes a checksum of the file data. Once the file(s) sizes exceed around 1GB, the mmap calls will fail because the memory from 0x00000000 - 0x40000000 has been exhausted. +Steps to reproduce: +1. Compile test application that mmaps entire files +2. Create 5 256MB test files +3. Run the program tell it to mmap all the files. The first 3 files succeed, but the 4th when run gets a -1 returned from mmap. +Additional information: +Lots of details on my github writeup and a demo of the bug in question. + +It seems that this 1GB limit is an artifact of where QEMU loaded the original ELF binary at (0x40000000). I've also been playing around with moving that address using the -B 0x80000000 option, but I've encountered other problems doing that. As I diagnose that, I figured I would write up this report on what I've seen so far incase I'm doing something dumb / creating a bad build or something. |