[issue16212] mmap() dumps core upon resizing the underlying file
Vladimir Ushakov added the comment: SIGBUS as well as SIGFPE or SIGSEGV is a synchronous signal. It is delivered to the thread that caused the trouble and the stack contents is well defined. https://www.securecoding.cert.org/confluence/display/seccode/SIG35-C.+Do+not+return+from+SIGSEGV,+SIGILL,+or+SIGFPE+signal+handlers Does not apply here: longjmp is not a return. https://www.securecoding.cert.org/confluence/display/seccode/SIG32-C.+Do+not+call+longjmp%28%29+from+inside+a+signal+handler The grounds are weak. They refer to SIG30-C, which is based on ISO C standard. POSIX explicitly declares the fact that longjmp is allowed to exit signal handlers as an extension to ISO C standard. (See http://pubs.opengroup.org/onlinepubs/9699919799/) Besides, POSIX explicitly states that only async-signal-safe functions can be called from the handlers, which are invoked asynchronously with process execution. That's not out case as mentioned above, we are not in asynchronous context as it could be with, say, SIGINT. (See http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html) Glibc doesn't mind as well: http://www.gnu.org/software/libc/manual/html_node/Longjmp-in-Handler.html I can doubt about non-POSIX platforms, but with POSIX everything seems clean to me. Especially since the method is already in use with SIGFPE. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16212] mmap() dumps core upon resizing the underlying file
Vladimir Ushakov added the comment: For your specific case, you should... There's nothing I should. As I said above, the bug doesn't trouble me. I just posted it as a generic contribution and don't really care whether it's going to be fixed or not. If decided so, I could help. Otherwise I'll just mind my business. :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16212] mmap() dumps core upon resizing the underlying file
Vladimir Ushakov added the comment: ...it's just impossible to guarantee that Python internal structures are still consistent. In generic case, I completely agree. Here the things are much simpler (unless I missed something). We know perfectly well the code we need to protect (mmap accessors). We can make the protected sections small enough to ensure that no internal state gets corrupted. I just feel, I can do it simply and safely. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16212] mmap() dumps core upon resizing the underlying file
Vladimir Ushakov added the comment: Update: The correct link to the POSIX definition of longjmp exiting a signal handler as an ISO C extension is http://pubs.opengroup.org/onlinepubs/9699919799/functions/longjmp.html -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16212] mmap() dumps core upon resizing the underlying file
Vladimir Ushakov added the comment: But I think we've talked enough... So do I. Let's go for it. I'll make a patch (which apparently takes some time) and post it here, we'll discuss it then. Thanks for your comments. Now I believe it's a bit harder than I thought initially, but still doable. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16212] mmap() dumps core upon resizing the underlying file
Vladimir Ushakov added the comment: I know how to avoid the problem in my case, the bug does not really affect me. I posted it because I thought that the possibility to crash the interpreter is something to be avoided at all costs. I've found a few examples of handling non-restartable signals with longjmps, but not that familiar with the codebase to estimate how reliably it can be done on all supported platforms. I don't really know how this code would behave, say, on Windows. I'm gonna do some research on the topic when I have a little more time. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16212] mmap() dumps core upon resizing the underlying file
Vladimir Ushakov added the comment: You can't use longjmp from signal handlers. Well, you can, but 99% of the code that does it is broken, because you can only call async-safe functions from within a signal handler, and certainly can't run the intepreter. I don't see the reason to run the interpreter. But a quick look at the source shows that the current implementation already uses longjmps to handle SIGFPE (see pyfpe.h and fpectlmodule.c). It seems to be in use on many platforms. The only problem I see so far is the possibility that we have to protect too much. However, as I could guess from quickly browsing through the mmap() implementation, the address of the mmap()ed region never leaves the module, all accesses are done using exported methods. If it is really the case, we can wrap them into something similar to PyFPE_START_PROTECT() and PyFPE_END_PROTECT() (see comments in pyfpe.h). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16212] mmap() dumps core upon resizing the underlying file
New submission from Vladimir Ushakov:
The following code crashes the interpreter on Linux:
#!/usr/bin/python3
import mmap
with open('test', 'wb') as f:
f.write(bytes(1))
with open('test', 'r+b') as f:
m = mmap.mmap(f.fileno(), 0)
f.truncate()
a = m[:]
---
It's not specific to the zero size truncation, it's enough if the file size
decreases beyond a page border.
--
components: IO
messages: 172745
nosy: Vladimir.Ushakov
priority: normal
severity: normal
status: open
title: mmap() dumps core upon resizing the underlying file
type: crash
versions: Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16212
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16212] mmap() dumps core upon resizing the underlying file
Vladimir Ushakov added the comment: I think, handling the signal would do. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16212 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
