You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
SIGBUS: writing to mmaped device beyond file size #119817
On POSIX, mmap operations can raise SIGBUS or SIGSEV, depending on the platform. Nothing is currently implemented to handle either signal. On Windows, mmap handles the corresponding exceptions for EXCEPTION_IN_PAGE_ERROR and EXCEPTION_ACCESS_VIOLATION by raising OSError instead of letting the default exception handler terminate the process.
The Windows code uses structured exception handling to do that, which is very different from POSIX signal handlers. It will complex to do this with signal handlers, if it is possible at all. Perhaps using setjmp/longjmp with thread-local buffers, but that would impose significant overhead on what might be a very hot code path.
It would also be a change in behaviour to install a handler for SIGBUS, not to mention SIGSEV(!), when we previously didn't.
Personally, as a POSIX mmap enjoyer, a SIGBUS/SIGSEV is exactly what I would expect and want to get in this scenario. YMMV of course.
This issue can also be reproduced with mapping to a regular file and then truncating it. Except on Windows, where you cannot simply truncate a mapped file.
Activity
Zheaoli commentedon Jun 1, 2024
May I ask if the
/sda3is your disk device?Zheaoli commentedon Jun 1, 2024
Can not reproduced on Linux 6.9
Semnodime commentedon Jun 4, 2024
@Zheaoli The bug is reproducible on
python3.12.3hosted on Linux kernel6.9.2-1-MANJARO.I suppose you overlooked the
blockdev --getsize64 $DEVstatement which implies the exact blockdevice size.Notice the
hellsh(hell shell) at the end.Zheaoli commentedon Jun 8, 2024
The issue confirmed, But I think it's not Python bug I think
The core reason here is that the file size is
1048576but you map a1048577memory to it. So the process SIGBUS nowYou need to take care of the SIGBUS when you use the
mmapAPIeryksun commentedon Jun 8, 2024
On POSIX,
mmapoperations can raiseSIGBUSorSIGSEV, depending on the platform. Nothing is currently implemented to handle either signal. On Windows,mmaphandles the corresponding exceptions forEXCEPTION_IN_PAGE_ERRORandEXCEPTION_ACCESS_VIOLATIONby raisingOSErrorinstead of letting the default exception handler terminate the process.Semnodime commentedon Nov 5, 2024
@eryksun
Is there unreasonable overhead if cpython is updated to also raise an
OSErroron POSIX?duaneg commentedon Jun 16, 2025
The Windows code uses structured exception handling to do that, which is very different from POSIX signal handlers. It will complex to do this with signal handlers, if it is possible at all. Perhaps using
setjmp/longjmpwith thread-local buffers, but that would impose significant overhead on what might be a very hot code path.It would also be a change in behaviour to install a handler for
SIGBUS, not to mentionSIGSEV(!), when we previously didn't.Personally, as a POSIX
mmapenjoyer, aSIGBUS/SIGSEVis exactly what I would expect and want to get in this scenario. YMMV of course.serhiy-storchaka commentedon Aug 29, 2025
This issue can also be reproduced with mapping to a regular file and then truncating it. Except on Windows, where you cannot simply truncate a mapped file.
Actually, #66234 is caused by using
mmap()internally ingdbm.