#6 0x00000001045c52a3 in base::SharedMemory::CreateOrOpen (this=0x1185efda8, name=@0x7fff5fbf78a0, posix_flags=514, size=143360) at /Volumes/SSD-Mac1/Users/benoitgirard/ssd-mozilla/mozilla-central/tree/ipc/chromium/src/base/shared_memory_posix.cc:224 224 DCHECK(mapped_file_ >= 0); (gdb) list 219 } 220 } 221 } 222 223 mapped_file_ = dup(fileno(fp)); 224 DCHECK(mapped_file_ >= 0); 225 226 struct stat st; 227 if (fstat(mapped_file_, &st)) 228 NOTREACHED(); (gdb) print fp $4 = (FILE *) 0x7fff7cd74010 (gdb) print errno $5 = <unknown type> (gdb) print (int)errno $6 = 24 (gdb) print fileno(fp) Unable to call function "fileno" at 0x7fff92406319: no return type information available. To call this function anyway, you can cast the return type explicitly (e.g. 'print (float) fabs (3.0)') (gdb) print (int)fileno(fp) $7 = 799

Are we allocating one shmem segment per tile?

(In reply to Chris Jones [:cjones] [:warhammer] from comment #1) > Are we allocating one shmem segment per tile? Yes, tiles are be recycled independently from each other. The number of tile is variable and changes frequently based on the android front-end viewport strategy. The tiling code is really not the place to act as an 'shmem allocator' to reduce shmem objects.

To be specific, we don't run into the 800 limit directly (the above coding was leaking tiles) but a cap of 800 shmem sounds like a real problem when you have tiles using a few dozens of them as well as other IPC components using them.

Tiles are 256x256 or 64x64 right? Was this in a debug build? We allocate two extra pages per Shmem to act as sentinels for out-of-bounds accesses. In an opt build, this is a max area of ~7240x7240 and a min of ~1810x1810 (ignoring other shmem users, which are basically none). Content can easily force us to exceed that limit, but content can DoS the gfx system in many many ways. We've discussed having a smarter shmem allocator a few times in the past but haven't had a strong reason to make one. This is another argument for one, but I don't think a compelling enough one to make this P1. Would recommend filing away.

IIRC the problem was that we ran out of FDs, not the shmem size.

Yes, I know. I was trying to gauge the severity of this problem. Let me put it more clearly: Since we can cover 7240x7240 pixels in the common case before running out of fds in the current less-than-optimally-allocated code, and we're not shipping this on OS X anytime soon, my recommendation is to file this away for another day. Make sense?