Re: 1.8.6, jemalloc, sock.close problem

I used to catch Errno::EINVAL when using lots of open file descriptors
and [ruby] threads on win32 [and probably still would except I went
single threaded and switched to Linux to side step the problem].
Never figured it out.  Sometimes sockets would 'read' one another's
data, too, and sometimes a close on one socket would close another
different socket.  I assume yours works splendidly with the normal
memory allocator?

-R

refs:
http://izumi.plan99.net/blog/index.php/2008/01/14/making-ruby's-garbage-collector-copy-on-write-friendly-part-7/

http://64.233.167.104/search?q=cache:Ilkzvy47LgcJ:permalink.gmane.org/gmane.comp.lang.ruby.mongrel.general/245+zed+shaw+rails+thread+safety&hl=en&gl=us&ct=clnk&cd=1

On Tue, May 27, 2008 at 3:16 PM, Christopher Thompson
<[e-mail]> wrote:
> Warning:  This message is probably only peripherally related to Ruby!
>
> In order to reduce the amount of memory that Ruby uses, we are trying to get
> Mozilla's (actually, FreeBSD's) jemalloc working in Ruby 1.8.6.
>
> Everything seems to work well EXCEPT that occasionally, a call to close a
> socket fails.  I can catch an Errno:EINVAL but for the life of me, I cannot
> figure out what could cause this.  It only happens occasionally.  I have not
> been able to find any other problems.  I suspect some sort of memory issue
> with jemalloc but running everything under valgrind shows no likely
> suspects.  I've tried debugging with Ruby 1.8.6-p114 and with
> 1.8.7-preview4, both show the same problem.
>
> If anyone has any ideas for avenues to debug this, I'd love to hear them.  I
> can't actually figure out the line of code in Ruby that's sending back the
> Errno:EINVAL; I've only been working with the Ruby code base for a short
> time.  And the fact that it only happens occasionally makes it really
> difficult to debug.
>
> For the record, using jemalloc instead of the linux or the osx default
> allocator takes slightly more CPU but results in significantly less memory
> usage for Ruby.
>
>