android ndk 32位,升級到棒棒糖后，Android NDK mmap調用在32位設備上被損壞。

4

At the point where the mmap() fails, open /proc/self/maps and copy the contents to a temp file, then examine the file in an editor. You should see a bunch of entries like this:

在mmap()失敗的地方，打開/proc/self/maps並將內容復制到臨時文件，然后在編輯器中檢查文件。你應該看到很多這樣的條目:

12e01000-42c00000 ---p 00201000 00:04 11639 /dev/ashmem/dalvik-main space (deleted)

55281000-5d500000 r--s 00000000 00:16 61 /storage/sdcard1/blah

5d500000-67e80000 rw-p 00000000 00:00 0 [anon:libc_malloc]

67ea4000-682cc000 r-xp 00000000 b3:17 114807 /system/vendor/lib/libsc-a3xx.so

682cc000-682f4000 r--p 00427000 b3:17 114807 /system/vendor/lib/libsc-a3xx.so

The numbers on the left are virtual address ranges (start / end) for the process. When you create a new mapping, it needs to fit in the gap between mappings.

左邊的數字是進程的虛擬地址范圍(開始/結束)。當您創建一個新的映射時，它需要適應映射之間的差異。

In the example above, there's a nice big gap between the end of the first entry at 0x42c00000 and the start of the next at 0x55281000. That's about 294MB. There's no space between the next two, and only a small one after that.

在上面的示例中，第一個條目在0x42c00000處的末尾與下一個條目在0x55281000處的開頭之間有很大的差距。大約294 mb。接下來的兩個之間沒有空間，只有一個小的。

If you look at your process map, and don't find a gap big enough to hold your file, you have your answer. The region between 0x00000000 and 0xbfffffff is generally available to 32-bit apps, but the app framework uses up a great deal of it. (The top 1GB is mapped to the kernel.)

如果您查看您的進程映射，但是沒有找到足夠大的間隔來保存文件，那么您就得到了您的答案。0x00000000和0xbfffffff之間的區域通常對32位的應用程序可用，但是應用程序框架使用了很多。(最上面的1GB被映射到內核。)

My guess is that some combination of ASLR and changes to the way virtual memory is allocated in Lollipop have led to this problem. In the map attached to this similar question, the largest gap found was about 300MB. There are two large "dalvik" regions, one 768MB (at 12e01000), one 1.2GB (at 84d81000). (Since you are running Lollipop these are actually due to ART rather than Dalvik, but apparently the label stuck.)

我的猜想是ASLR的一些組合和對棒棒糖中分配虛擬內存的方式的改變導致了這個問題。在與這個類似問題相關的地圖中，發現的最大差距約為300MB。有兩個較大的“dalvik”區域，一個768MB (12e01000)，一個1.2GB (84d81000)。(既然你在跑棒棒糖，這些其實是藝術而不是Dalvik，但很明顯這個標簽被卡住了。)

One possibility is that ART has higher virtual memory requirements than Dalvik did, and the large allocations are making it difficult for applications to get large mapped regions. It's also possible that ART is over-allocating due to a bug. You may want to test on Marshmallow to see if something got fixed.

一種可能性是，ART比Dalvik需要更高的虛擬內存，而大量的分配使得應用程序很難獲得更大的映射區域。也有可能是由於一個bug導致了藝術的過度分配。您可能想要在棉花糖上進行測試，看看是否有什么東西被修復了。

Whatever the case, you can't create a mapping if there isn't a contiguous virtual memory address region large enough to hold it. With the app framework usage and the enormous ART allocations seen in the other question, a 768MB mapping wouldn't be possible even if the virtual address space weren't fragmented. You will need to map smaller sections of the file, and possibly un-map them as you work to make room.

無論哪種情況，如果沒有足夠大的連續虛擬內存地址區域來容納它，就不能創建映射。由於應用程序框架的使用和在另一個問題中看到的巨大的藝術分配，即使虛擬地址空間不是分散的，也不可能實現768MB的映射。您將需要映射文件的更小的部分，並可能在工作時取消它們的映射以騰出空間。

It might be worth filing a bug on b.android.com. Attach a copy of your process map file, and be specific about version of Android and device.

在b.android.com上發布一個錯誤可能是值得的。附上你的進程地圖文件的副本，並且要特別說明Android和設備的版本。

For a bit more about interpreting /proc/maps output, see e.g. this answer.

有關解釋/proc/maps輸出的更多信息，請參見這個答案。