Shmem runs into an 800 descriptor limit on OS X

NEW
Unassigned

Status

()

Core
IPC
6 years ago
6 years ago

People

(Reporter: BenWa, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
#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
(Reporter)

Updated

6 years ago
Blocks: 747811
Are we allocating one shmem segment per tile?
(Reporter)

Comment 2

6 years ago
(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.
(Reporter)

Comment 3

6 years ago
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?
You need to log in before you can comment on or make changes to this bug.