Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


ruby 1.9.3-p194 on windows lead to segfault #319

alor opened this Issue · 14 comments

7 participants


i've upgraded ruby from 1.9.3-p125 to 1.9.3-p194 from rubinstaller. i'm using eventmachine 1.0.0.beta.4.1
now eventmachine segfault on run_machine.

i know that something has changed in rubyinstaller regarding the FD_SETSIZE:

and there is an open issue on eventmachine as well:

how can i create a beta 4.1 from the current repository? which are the differences between beta 4 and 4.1?
i've tried cloning the current repo and applying the 303 patch, but eventmachine now uses 50% of CPU and does not accept SSL connections anymore.

any suggestion?

this is the dump:

K:/Ruby/lib/ruby/gems/1.9.1/gems/eventmachine-1.0.0.beta.4.1-x86-mingw32/lib/eventmachine.rb:179: [BUG] Segmentation fault
ruby 1.9.3p194 (2012-04-20) [i386-mingw32]

-- Control frame information -----------------------------------------------
c:0008 p:---- s:0034 b:0034 l:000033 d:000033 CFUNC :run_machine
c:0007 p:0248 s:0031 b:0031 l:000030 d:000030 METHOD K:/Ruby/lib/ruby/gems/1.9.1/gems/eventmachine-1.0.0.beta.4.1-x86-mingw32/lib/eventmachine.rb:179
c:0006 p:0023 s:0024 b:0024 l:0026a4 d:0026a4 METHOD K:/Server/lib/server/events.rb:152
c:0005 p:0604 s:0019 b:0019 l:000018 d:000018 METHOD K:/Server/lib/server/server.rb:90
c:0004 p:0025 s:0011 b:0011 l:000010 d:000010 METHOD K:/Server/lib/server/server.rb:106
c:0003 p:0094 s:0007 b:0006 l:00048c d:000f4c EVAL bin/server:7
c:0002 p:---- s:0004 b:0004 l:000003 d:000003 FINISH
c:0001 p:0000 s:0002 b:0002 l:00048c d:00048c TOP

-- Ruby level backtrace information ----------------------------------------
bin/server:7:in <main>'
K:/Server/lib/server/server.rb:90:in run'
K:/Ruby/lib/ruby/gems/1.9.1/gems/eventmachine-1.0.0.beta.4.1-x86-mingw32/lib/eventmachine.rb:179:in run'

-- C level backtrace information -------------------------------------------
C:\Windows\SysWOW64\ntdll.dll(ZwWaitForSingleObject+0x15) [0x77a7f8b1]
C:\Windows\syswow64\kernel32.dll(WaitForSingleObjectEx+0x43) [0x75aa1194]
C:\Windows\syswow64\kernel32.dll(WaitForSingleObject+0x12) [0x75aa1148]
K:\Ruby\bin\msvcrt-ruby191.dll(rb_vm_bugreport+0xf9) [0x62e5c589]
K:\Ruby\bin\msvcrt-ruby191.dll(rb_name_err_mesg_new+0x17a) [0x62d3a7e2]
K:\Ruby\bin\msvcrt-ruby191.dll(rb_bug+0x2f) [0x62d3b4fb]
K:\Ruby\bin\msvcrt-ruby191.dll(rb_check_safe_str+0x1a4) [0x62dee168]
C:\Windows\syswow64\kernel32.dll(GetProfileStringW+0x12aa3) [0x75ae003f]
C:\Windows\SysWOW64\ntdll.dll(RtlKnownExceptionFilter+0xb7) [0x77ad74df]


It's because the pull request has not been merged yet.
The main issue is with line 85 of project.h

If that line is removed the seg fault will no longer occur


i've forked the em repo and applied your pull request. the segfault is gone, but i've problems with cpu usage and ssl connections.... any ideas?


Is it that SSL just doen't work?
I could never get that to compile properly either.

CPU usage is interesting, how significant is the difference?


the ssl problem is why i was asking which are the differences between beta.4 and 4.1 i just wanted to compile a clean em with ssl support. SSL works in the beta.4.1 gem.

the process is stuck at 50% of the processor, since it is dual core, it basically takes as much as possible. probably a strict busy loop.


Very weird.. I haven't experienced the CPU issue.
Hmm. I thought I forked after 4.1 was released.

You could try forking the main project and just removing the #define FD_SETSIZE 1024 line see if that works


i'm investigating and probably the CPU usage is not related to event machine... if i completely turn of the the cpu usage is still very high.

no success with SSL support though... :(


I had the same segfault, and have similarly solved it by commenting out line 85 of ext\project.h: #define FD_SETSIZE 1024.

This is being compiled for Ruby 1.9.3-p194 on Windows (RubyInstaller version) with the latest DevKit version.


I'm getting the same segmentation fault.

Solved by uninstalling the eventmachine gem, and then running bundle install.


Hello guys,

The issue you're experiencing here between RubyInstaller 1.9.3-p194 and pre-compiled EventMachine is covered in the announcement notes of RubyInstaller:

= Q: What means by "increased file descriptors", how that affects me?

A: By default Ruby 1.9 was limited to 64 sockets when using select() function.
select() is a mechanism to set and clear the state of sockets that are waiting
for data. In other OS you have different 'pooling' mechanisms.

Most of the web servers that run on Ruby, specially the evented ones depends
on select().

Without this change these frameworks/libraries wouldn't be able to use more
than 64 open sockets, which affects any of us attempting to use Ruby on Windows
for more than testing things out.

Please note that this is a workaround to a bigger issue: select() and the
associated functions are not the recommended or optimally way to interact with
sockets on Windows.

If you encounter a problem running a pre-compiled evented library against this
build, please ask the library author to recompile with -DFD_SETSIZE=32767

Now, the background issue is that Ruby itself replaced FD_SET and friends, it was not EventMachine fault.

A bug was reported to Ruby and was solved:

We hope backport it for next 1.9.3 patchlevel release.

As a short-term solution, you need to recompile any pre-compiled extension that depends on a select() or FD_* macros.


Cool! So to be clear, this patch you referenced above means ruby will effectively ignore anything that is defined in eventmachine and use the FD_SET as defined by ruby.

Will this mean that (Ruby with FD_SET defined as 32767 and EM with FD_SET at 1024) eventmachine can use more than 1024 sockets or will this still be a limitation?


Cool! So to be clear, this patch you referenced above means ruby will effectively ignore anything that is defined in eventmachine and use the FD_SET as defined by ruby.

Hmm, no. If EventMachine redefines FD_SETSIZE, right now it will crash. With Ruby fixes (once released) it will not.

Short term workaround: either compile EventMachine with same FD_SETSIZE or completely comment it out so it uses Ruby's FD_SETSIZE value.

Will this mean that (Ruby with FD_SET defined as 32767 and EM with FD_SET at 1024) eventmachine can use more than 1024 sockets or will this still be a limitation?

With Ruby fix: EventMachine will be limited to 1024 sockets if FD_SETSIZE is at 1024.


Thanks for clarifying and great work!


I still see this issue with eventmachine-1.0.0.rc.1. The rc1 release has commented the line to set FD_SETSIZE.

Here is my stacktrace:

C:/Ruby193/lib/ruby/gems/1.9.1/gems/eventmachine-1.0.0.rc.1-x86-mingw32/lib/eventmachine.rb:187: [BUG] Segmentation fault
ruby 1.9.3p194 (2012-04-20) [i386-mingw32]

-- Control frame information -----------------------------------------------
c:0013 p:---- s:0045 b:0045 l:000044 d:000044 CFUNC  :run_machine
c:0012 p:0325 s:0042 b:0042 l:000041 d:000041 METHOD C:/Ruby193/lib/ruby/gems/1.9.1/gems/eventmachine-1.0.0.rc.1-x86-mingw32/lib/eventmachine.rb:187
c:0011 p:0066 s:0035 b:0035 l:001e08 d:001e08 METHOD C:/Ruby193/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/backends/base.rb:61
c:0010 p:0143 s:0031 b:0031 l:000030 d:000030 METHOD C:/Ruby193/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/server.rb:159
c:0009 p:0545 s:0028 b:0028 l:000e88 d:000e88 METHOD C:/Ruby193/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/controllers/controller.rb:86
c:0008 p:0283 s:0024 b:0024 l:000023 d:000023 METHOD C:/Ruby193/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/runner.rb:185
c:0007 p:0037 s:0019 b:0019 l:000018 d:000018 METHOD C:/Ruby193/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/runner.rb:151
c:0006 p:0042 s:0016 b:0016 l:000015 d:000015 TOP    C:/Ruby193/lib/ruby/gems/1.9.1/gems/thin-1.3.1/bin/thin:6
c:0005 p:---- s:0014 b:0014 l:000013 d:000013 FINISH
c:0004 p:---- s:0012 b:0012 l:000011 d:000011 CFUNC  :load
c:0003 p:0167 s:0008 b:0008 l:001e14 d:000dc4 EVAL   C:/Ruby193/bin/thin:23
c:0002 p:---- s:0004 b:0004 l:000003 d:000003 FINISH
c:0001 p:0000 s:0002 b:0002 l:001e14 d:001e14 TOP

@kandadaboggu please read Issue #333

@tmm1 tmm1 closed this
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.