We get a release assert in Connection::processMessage() when trying to get a file descriptor from m_fileDescriptors array that is empty.

STDERR: warning: core file may not match specified executable file.
STDERR: 1   0x7f37667cbdf9 WTFCrash
STDERR: 2   0x7f3768c58167 IPC::Connection::processMessage()
STDERR: 3   0x7f3768c58730 IPC::Connection::readyReadHandler()
STDERR: 4   0x7f3768c5895d /home/slave/webkitgtk/gtk-linux-64-release/build/WebKitBuild/Release/lib/libwebkit2gtk-4.0.so.37(+0x1e4295d) [0x7f3768c5895d]
STDERR: 5   0x7f376177fe99 /home/slave/webkitgtk/gtk-linux-64-release-tests/build/WebKitBuild/DependenciesGTK/Root/lib/libgio-2.0.so.0(+0x8de99) [0x7f376177fe99]
STDERR: 6   0x7f37615c56b8 g_main_context_dispatch
STDERR: 7   0x7f37615c5a78 /home/slave/webkitgtk/gtk-linux-64-release-tests/build/WebKitBuild/DependenciesGTK/Root/lib/libglib-2.0.so.0(+0x4ca78) [0x7f37615c5a78]
STDERR: 8   0x7f37615c5d62 g_main_loop_run
STDERR: 9   0x7f3766847b50 WTF::RunLoop::run()
STDERR: 10  0x7f37667eb19b WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*)
STDERR: 11  0x7f37668490a9 /home/slave/webkitgtk/gtk-linux-64-release/build/WebKitBuild/Release/lib/libjavascriptcoregtk-4.0.so.18(+0x12350a9) [0x7f37668490a9]
STDERR: 12  0x7f3763765fa3 /lib/x86_64-linux-gnu/libpthread.so.0(+0x7fa3) [0x7f3763765fa3]
STDERR: 13  0x7f37600534cf clone

The problem is that since r257667, a shared buffer is always used by the network process to send data to the web process (NetworkResourceLoader::sendBuffer) and shared buffer encoding/decoding was changed to always use shared memory and send the file descriptor over the IPC. When sending large data in small chunks like these tests are doing, we easily end up with many messages queued in the web process receiver (Connection::enqueueIncomingMessage), all of them having one file descriptor open. When the maximum number of open file descriptors per process is reached, recvmsg doesn't fail but it sets the flag MSG_CTRUNC in msg_flags and the file descriptor is not actually included as part of the control message. The message info still claims to include a file descriptor, but it hasn't been created and added to the m_fileDescriptors array. We could check msg_flags, but only to assert earlier, not to fix the problem, since we are unable to get the file descriptor sent. So, at least in linux I think it's better to send the data over the IPC instead of using shared memory. We are already using shared memory for any IPC message bigger than 4096.