Skip to content
This repository

error: System.SendFile.Darwin: invalid argument (Socket is not connected) #91

Open
spockz opened this Issue August 14, 2011 · 12 comments

3 participants

Alessandro Vermeulen Gregory Collins Heinrich Apfelmus
Alessandro Vermeulen

When serving large static files you get the error below when you run out of file handles. I know you aren't supposed to do this with snap but nonetheless it should not crash the server.

14/Aug/2011:17:04:17 +0100] [192.168.25.85]: error: System.SendFile.Darwin: invalid argument (Socket is not connected)

Gregory Collins
Alessandro Vermeulen

It really crashes the server process, so we probably should catch the exception at some point. But I'm not sure where would be best. Maybe you want a general catch somewhere before the dispatcher to log your errors?

Gregory Collins
Heinrich Apfelmus

I would like to bump this issue. It appears that the snap server is unable to serve a ~15 MB file on OS X when run from GHCi, yielding the error as above. Minimal code to reproduce. Any workaround?

Heinrich Apfelmus HeinrichApfelmus referenced this issue in HeinrichApfelmus/threepenny-gui May 17, 2013
Closed

Mirror local files via the web server #25

Gregory Collins
Owner

@HeinrichApfelmus I can't reproduce this -- I just loaded your example program up in GHCi and served a 2GB file with no problems.

λ  uname -a
Darwin cronus.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64
λ  ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.4.2
Heinrich Apfelmus

Weird. My version data is

λ uname -a
Darwin winter-wind.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
λ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.4.1

The issue is similar for the warp server, and someone could reproduce it on Linux with GHC 7.6.3.

Does the web browser have an influence? I'm using Chrome. It sometimes works in Safari, but not always.

Gregory Collins
Owner

I have a theory here. Could you rebuild your snap-core with the "-fdebug" flag (and the rest of your project downstream of it), and then run ghci with DEBUG=1 set in the environment? If the sendfile() call never blocks then the timeout action may never trigger, causing your thread to be killed. Would like to see a trace dump here, if only to rule out the timeout manager as a possible cause.

Heinrich Apfelmus

I performed the steps as you indicated. The folks at yesodweb/wai#157 have figured out that the issue is apparently browser related. Here are the debug logs for Chrome (fails) and Firefox (suceeds!).

Gregory Collins
Owner

After reading yesodweb/wai#157 -- does this still happen if you put an appropriate Content-Type on the response?

Heinrich Apfelmus

Nice, using serveFileAs "video/mp4" instead of serveFile works! A player is displayed and the video loads completely. Serving as application/octet-stream doesn't work, though.

I'm still confused as to why that happens, though. Apparently, Chrome decides to stop receiving large amounts of data if it doesn't know what to do with them (which might make sense, because it could be a bug in the web server where it simply prints never ending garbage.)

On the other hand, doesn't that mean that serveFile should deprecated in favor of serveFileAs? Or at least emit a warning when no suitable MIME type can be guessed? Apparently, ",mp4" is not in Snap.Util.FileServe.defaultMimeTypes.

Gregory Collins
Owner

I'll add this mime type to our default table.

Heinrich Apfelmus

In that case, it would be great if you could add a note to the documentation of the serveFile function along the lines of

The MIME type of the file to be served is determined from the file ending by using the 'defaultMimeTypes' table. For maximum browser compatibility, it is recommended that you always serve files with a good MIME type. Use `serveFileAs` if your type is not included in the default table.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.