<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Mmap on Nalar</title>
    <link>https://nalar.dev/tags/mmap/</link>
    <description>Recent content in Mmap on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Thu, 17 Sep 2026 00:00:00 +0700</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/mmap/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Truncating a Mapped File Can Trigger SIGBUS</title>
      <link>https://nalar.dev/truncating-a-mapped-file-can-trigger-sigbus/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/truncating-a-mapped-file-can-trigger-sigbus/</guid>
      <description>&lt;p&gt;A process can retain a valid &lt;code&gt;mmap()&lt;/code&gt; address range after another operation shrinks the backing file, then receive &lt;code&gt;SIGBUS&lt;/code&gt; when it touches a mapped page past the file&amp;rsquo;s new end. The mapping itself has not vanished. Its backing object no longer covers every page that the virtual mapping originally referenced.&lt;/p&gt;&#xA;&lt;p&gt;This boundary is easy to miss because mapping lifetime and file size are separate state. Closing the original file descriptor does not invalidate an established mapping, and shrinking the file does not act like &lt;code&gt;munmap()&lt;/code&gt; on every process that maps it.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
