Ruby Issue Tracking System: Issueshttps://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112016-02-26T20:49:28ZRuby Issue Tracking System
Redmine Ruby master - Bug #12117 (Closed): UDPSocket.new crash on win32 with "rb_update_max_fd: invalid f...https://bugs.ruby-lang.org/issues/121172016-02-26T20:49:28Zspatulasnout (B Kelly)billk@cts.com
<p>OS is Windows 7. The following command line reproduces the issue:</p>
<p>$ ruby22 -rsocket -e "UDPSocket.new(Socket::AF_INET)"</p>
<p>Output is:</p>
<pre><code>-e:1: [BUG] rb_update_max_fd: invalid fd (176) given.
ruby 2.2.5p241 (2016-02-24 revision 53909) [i386-mswin32_100]
-- Control frame information -----------------------------------------------
c:0004 p:---- s:0010 e:000009 CFUNC :initialize
c:0003 p:---- s:0008 e:000007 CFUNC :new
c:0002 p:0020 s:0004 E:001964 EVAL -e:1 [FINISH]
c:0001 p:0000 s:0002 E:000574 TOP [FINISH]
-- Ruby level backtrace information ----------------------------------------
-e:1:in `<main>'
-e:1:in `new'
-e:1:in `initialize'
-- C level backtrace information -------------------------------------------
C:\Windows\SysWOW64\ntdll.dll(NtWaitForSingleObject+0x15) [0x76FBF971]
C:\Windows\syswow64\kernel32.dll(WaitForSingleObjectEx+0x43) [0x76861194]
C:\Windows\syswow64\kernel32.dll(WaitForSingleObject+0x12) [0x76861148]
M:\dev\ruby-current\bin\msvcr100-ruby220.dll(rb_print_backtrace+0x2f) [0x722037FE] p:\code\ruby-git\ruby_2_2\vm_dump.c:712
M:\dev\ruby-current\bin\msvcr100-ruby220.dll(rb_vm_bugreport+0x64) [0x72203864] p:\code\ruby-git\ruby_2_2\vm_dump.c:978
M:\dev\ruby-current\bin\msvcr100-ruby220.dll(rb_bug+0x3f) [0x72188331] p:\code\ruby-git\ruby_2_2\error.c:409
M:\dev\ruby-current\bin\msvcr100-ruby220.dll(rb_update_max_fd+0x42) [0x7217784C] p:\code\ruby-git\ruby_2_2\io.c:211
M:\dev\ruby-current\lib\ruby\2.2.0\i386-mswin32_100\socket.so(rsock_socket0+0x22) [0x683E1629] p:\code\ruby-git\ruby_2_2\ext\socket\init.c:319
M:\dev\ruby-current\lib\ruby\2.2.0\i386-mswin32_100\socket.so(rsock_socket+0x12) [0x683E1641] p:\code\ruby-git\ruby_2_2\ext\socket\init.c:330
M:\dev\ruby-current\lib\ruby\2.2.0\i386-mswin32_100\socket.so(udp_init+0x40) [0x683E988E] p:\code\ruby-git\ruby_2_2\ext\socket\udpsocket.c:37
M:\dev\ruby-current\bin\msvcr100-ruby220.dll(call_cfunc_m1+0xf) [0x72169090] p:\code\ruby-git\ruby_2_2\vm_insnhelper.c:1208
M:\dev\ruby-current\bin\msvcr100-ruby220.dll(vm_call0_cfunc_with_frame+0xd9) [0x7216D5CE] p:\code\ruby-git\ruby_2_2\vm_eval.c:127
M:\dev\ruby-current\bin\msvcr100-ruby220.dll(vm_call0_body+0x142) [0x72173264] p:\code\ruby-git\ruby_2_2\vm_eval.c:184
M:\dev\ruby-current\bin\msvcr100-ruby220.dll(vm_call0+0x38) [0x7217391B] p:\code\ruby-git\ruby_2_2\vm_eval.c:59
M:\dev\ruby-current\bin\msvcr100-ruby220.dll(rb_call0+0x64) [0x72173A6E] p:\code\ruby-git\ruby_2_2\vm_eval.c:349
M:\dev\ruby-current\bin\msvcr100-ruby220.dll(rb_call+0x22) [0x72173B4C] p:\code\ruby-git\ruby_2_2\vm_eval.c:616
M:\dev\ruby-current\bin\msvcr100-ruby220.dll(rb_funcallv+0x16) [0x72173C3B] p:\code\ruby-git\ruby_2_2\vm_eval.c:831
M:\dev\ruby-current\bin\msvcr100-ruby220.dll(rb_obj_call_init+0x32) [0x721424FC] p:\code\ruby-git\ruby_2_2\eval.c:1364
M:\dev\ruby-current\bin\msvcr100-ruby220.dll(rb_class_new_instance+0x1a) [0x72158B37] p:\code\ruby-git\ruby_2_2\object.c:1862
M:\dev\ruby-current\bin\msvcr100-ruby220.dll(call_cfunc_m1+0xf) [0x72169090] p:\code\ruby-git\ruby_2_2\vm_insnhelper.c:1208
M:\dev\ruby-current\bin\msvcr100-ruby220.dll(vm_call_cfunc_with_frame+0xe2) [0x7216C7A2] p:\code\ruby-git\ruby_2_2\vm_insnhelper.c:1380
M:\dev\ruby-current\bin\msvcr100-ruby220.dll(vm_call_cfunc+0x35) [0x7216C84F] p:\code\ruby-git\ruby_2_2\vm_insnhelper.c:1473
M:\dev\ruby-current\bin\msvcr100-ruby220.dll(vm_call_general+0x24f) [0x7216F848] p:\code\ruby-git\ruby_2_2\vm_insnhelper.c:1844
M:\dev\ruby-current\bin\msvcr100-ruby220.dll(vm_exec_core+0xadc) [0x721708DC] p:\code\ruby-git\ruby_2_2\insns.def:1070
M:\dev\ruby-current\bin\msvcr100-ruby220.dll(vm_exec+0x44d) [0x7217258B] p:\code\ruby-git\ruby_2_2\vm.c:1435
M:\dev\ruby-current\bin\msvcr100-ruby220.dll(rb_iseq_eval_main+0x64) [0x721726BA] p:\code\ruby-git\ruby_2_2\vm.c:1680
M:\dev\ruby-current\bin\msvcr100-ruby220.dll(ruby_exec_internal+0xc5) [0x7214147F] p:\code\ruby-git\ruby_2_2\eval.c:255
M:\dev\ruby-current\bin\msvcr100-ruby220.dll(ruby_exec_node+0x14) [0x72141520] p:\code\ruby-git\ruby_2_2\eval.c:317
M:\dev\ruby-current\bin\msvcr100-ruby220.dll(ruby_run_node+0x29) [0x72143549] p:\code\ruby-git\ruby_2_2\eval.c:309
M:\dev\ruby-current\bin\ruby22.exe(main+0x30) [0x011B1030] p:\code\ruby-git\ruby_2_2\main.c:36
M:\dev\ruby-current\bin\ruby22.exe(__tmainCRTStartup+0x122) [0x011B11C1] f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c:555
C:\Windows\syswow64\kernel32.dll(BaseThreadInitThunk+0x12) [0x7686338A]
C:\Windows\SysWOW64\ntdll.dll(RtlInitializeExceptionChain+0x63) [0x76FD9A02]
-- Other runtime information -----------------------------------------------
* Loaded script: -e
* Loaded features:
0 enumerator.so
1 rational.so
2 complex.so
3 M:/dev/ruby-current/lib/ruby/2.2.0/i386-mswin32_100/enc/encdb.so
4 M:/dev/ruby-current/lib/ruby/2.2.0/i386-mswin32_100/enc/trans/transdb.so
5 M:/dev/ruby-current/lib/ruby/2.2.0/i386-mswin32_100/enc/windows_1252.so
6 M:/dev/ruby-current/lib/ruby/2.2.0/unicode_normalize.rb
7 M:/dev/ruby-current/lib/ruby/2.2.0/i386-mswin32_100/rbconfig.rb
8 thread.rb
9 M:/dev/ruby-current/lib/ruby/2.2.0/i386-mswin32_100/thread.so
10 M:/dev/ruby-current/lib/ruby/2.2.0/rubygems/compatibility.rb
11 M:/dev/ruby-current/lib/ruby/2.2.0/rubygems/defaults.rb
12 M:/dev/ruby-current/lib/ruby/2.2.0/rubygems/deprecate.rb
13 M:/dev/ruby-current/lib/ruby/2.2.0/rubygems/errors.rb
14 M:/dev/ruby-current/lib/ruby/2.2.0/rubygems/version.rb
15 M:/dev/ruby-current/lib/ruby/2.2.0/rubygems/requirement.rb
16 M:/dev/ruby-current/lib/ruby/2.2.0/rubygems/platform.rb
17 M:/dev/ruby-current/lib/ruby/2.2.0/rubygems/basic_specification.rb
18 M:/dev/ruby-current/lib/ruby/2.2.0/rubygems/stub_specification.rb
19 M:/dev/ruby-current/lib/ruby/2.2.0/rubygems/util/stringio.rb
20 M:/dev/ruby-current/lib/ruby/2.2.0/rubygems/specification.rb
21 M:/dev/ruby-current/lib/ruby/2.2.0/rubygems/exceptions.rb
22 M:/dev/ruby-current/lib/ruby/2.2.0/rubygems/core_ext/kernel_gem.rb
23 M:/dev/ruby-current/lib/ruby/2.2.0/monitor.rb
24 M:/dev/ruby-current/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb
25 M:/dev/ruby-current/lib/ruby/2.2.0/rubygems.rb
26 M:/dev/ruby-current/lib/ruby/2.2.0/i386-mswin32_100/socket.so
27 M:/dev/ruby-current/lib/ruby/2.2.0/socket.rb
[NOTE]
You may have encountered a bug in the Ruby interpreter or extension libraries.
Bug reports are welcome.
For details: http://www.ruby-lang.org/bugreport.html
</code></pre>
<p>Was not able to reproduce the problem under OS X.</p>
<p>But it's happening on both of our Windows 7 systems.</p>
<p>Regards,</p>
<p>Bill</p> Ruby master - Bug #9737 (Closed): Non-ASCII characters in the path to ruby executable break requi...https://bugs.ruby-lang.org/issues/97372014-04-13T03:01:57Zspatulasnout (B Kelly)billk@cts.com
<p>Hi,</p>
<p>On Windows, if non-ASCII characters exist the path on which the ruby<br>
interpreter is invoked, the character encoding is not handled properly<br>
when the require paths in $: are created, making ruby unable to require<br>
libraries in its standard lib paths.</p>
<p>In the first two examples, the working directory of the shell is not<br>
a factor; what matters is the path by which the ruby interpreter is<br>
invoked.</p>
<p>Here we invoke ruby using a path containing non-ASCII characters:</p>
<pre><code>$ M:\dev\ruby-build\zz-können2\bin\ruby.exe -v --disable-gems -e "p $:.first.encoding, $:.first; require 'uri'"
ruby 2.2.0dev (2014-04-12 trunk 45576) [i386-mswin32_100]
#<Encoding:ASCII-8BIT>
"M:/dev/ruby-build/zz-k\xF6nnen2/lib/ruby/site_ruby/2.2.0"
-e:1:in `require': cannot load such file -- uri (LoadError)
from -e:1:in `<main>'
</code></pre>
<p>Here we invoke ruby in the same location, but instead using the<br>
NTFS "short" name on the path so that it is ASCII only:</p>
<pre><code>$ M:\dev\ruby-build\ZZ-KNN~2\bin\ruby.exe -v --disable-gems -e "p $:.first.encoding, $:.first; require 'uri'"
ruby 2.2.0dev (2014-04-12 trunk 45576) [i386-mswin32_100]
#<Encoding:IBM437>
"M:/dev/ruby-build/ZZ-KNN~2/lib/ruby/site_ruby/2.2.0"
</code></pre>
<p>In the second two examples, we change the working dir instead of<br>
specifying the interpreter path directly. The results are the same:</p>
<pre><code># working dir: M:\dev\ruby-build\zz-können2\bin
$ .\ruby.exe -v --disable-gems -e "p $:.first.encoding, $:.first; require 'uri'"
ruby 2.2.0dev (2014-04-12 trunk 45576) [i386-mswin32_100]
#<Encoding:ASCII-8BIT>
"M:/dev/ruby-build/zz-k\xF6nnen2/lib/ruby/site_ruby/2.2.0"
-e:1:in `require': cannot load such file -- uri (LoadError)
from -e:1:in `<main>'
# working dir: M:\dev\ruby-build\ZZ-KNN~2\bin
$ .\ruby.exe -v --disable-gems -e "p $:.first.encoding, $:.first; require 'uri'"
ruby 2.2.0dev (2014-04-12 trunk 45576) [i386-mswin32_100]
#<Encoding:IBM437>
"M:/dev/ruby-build/ZZ-KNN~2/lib/ruby/site_ruby/2.2.0"
</code></pre>
<p>I'm guessing this will be related to the <code>GetModuleFileName()</code> call in:</p>
<pre><code>win32/stub.c: lenexe = (size_t)GetModuleFileName(NULL, exename, sizeof exename);
</code></pre>
<p>which would presumably need to become the Unicode <code>GetModuleFileNameW()</code><br>
version instead?</p>
<p>Regards,</p>
<p>Bill</p> Ruby master - Bug #4198 (Rejected): parse error involving spaceship operatorhttps://bugs.ruby-lang.org/issues/41982010-12-24T09:30:41Zspatulasnout (B Kelly)billk@cts.com
<p>=begin<br>
Hi,</p>
<p>I'm not sure if this is a bug? I'm getting a parse error on<br>
the last line of the following code, unless I add parenthesis:</p>
<p>op-test-simple.rb</p>
<pre><code>class Opper
def / (other)
self
end
def + (other)
self
end
def <=> (other)
self
end
end
foo = Opper.new("foo")
bar = Opper.new("bar")
baz = Opper.new("baz")
quux = Opper.new("quux")
joe = Opper.new("joe")
mama = Opper.new("mama")
so = Opper.new("so")
fat = Opper.new("fat")
quick = Opper.new("quick")
brown = Opper.new("brown")
fox = Opper.new("fox")
foo + bar /
baz + quux /
joe + mama <=> so + fat /
quick + brown <=> fox
</code></pre>
<p>$ ruby19 -v op-test-simple.rb<br>
ruby 1.9.2p110 (2010-12-20 revision 30269) [i386-darwin10.4.0]<br>
op-test-simple.rb:29: syntax error, unexpected tCMP<br>
quick + brown <=> fox<br>
^<br>
op-test-simple.rb:29: warning: useless use of a variable in void context</p>
<p>However, if parenthesis are added, like:</p>
<p>(quick + brown <=> fox)</p>
<p>or:</p>
<p>quick + (brown <=> fox)</p>
<p>then the parse error does not occur.</p>
<p>Regards,</p>
<p>Bill<br>
=end</p> Ruby master - Bug #3523 (Third Party's Issue): win32 exception c0000029 on exit using fibershttps://bugs.ruby-lang.org/issues/35232010-07-02T22:42:31Zspatulasnout (B Kelly)billk@cts.com
<p>=begin<br>
Hi,</p>
<p>I'm encountering a windows exception c0000029 crash when my application (which uses fibers) runs on v1.9.2. The program runs to completion, and its tests all pass, but the exception occurs when ruby exits.</p>
<p>So far the crash happens consistently on v1.9.2-dev, but never happens on trunk (1.9.3-dev).</p>
<p>I will attempt to isolate a small bit of code which reproduces the problem. But I wanted to post in the meantime in case anyone might have ideas about what could cause this exception, or why it might differ between 1.9.2 and trunk.</p>
<p>Thanks,</p>
<p>Regards,</p>
<p>Bill<br>
=end</p> Ruby master - Bug #2278 (Closed): (windows) RbConfig sitearchdir differs from $: pathhttps://bugs.ruby-lang.org/issues/22782009-10-26T23:29:46Zspatulasnout (B Kelly)billk@cts.com
<p>=begin<br>
Hi,</p>
<p>It seems in ruby 1.9.2dev, on windows, 'sitearch' may differ between<br>
RbConfig vs. ruby_initial_load_paths[].</p>
<p>In RbConfig, 'sitearch' is i386-msvcr71:</p>
<p>arch => i386-mswin32_71<br>
sitearch => i386-msvcr71<br>
ruby_version => 1.9.1<br>
rubylibdir => M:/dev/ruby-build/v1_9_2/lib/ruby/1.9.1<br>
archdir => M:/dev/ruby-build/v1_9_2/lib/ruby/1.9.1/i386-mswin32_71<br>
sitelibdir => M:/dev/ruby-build/v1_9_2/lib/ruby/site_ruby/1.9.1<br>
sitearchdir => M:/dev/ruby-build/v1_9_2/lib/ruby/site_ruby/1.9.1/i386-msvcr71</p>
<p>But in $: it is i386-mswin32_71:</p>
<p>M:/dev/ruby-build/v1_9_2/lib/ruby/site_ruby/1.9.1<br>
M:/dev/ruby-build/v1_9_2/lib/ruby/site_ruby/1.9.1/i386-mswin32_71<br>
M:/dev/ruby-build/v1_9_2/lib/ruby/site_ruby<br>
M:/dev/ruby-build/v1_9_2/lib/ruby/1.9.1<br>
M:/dev/ruby-build/v1_9_2/lib/ruby/1.9.1/i386-mswin32_71</p>
<p>This is causing native extensions using extconf.rb to install into i386-msvcr71,<br>
but ruby can't find them since it's looking in i386-mswin32_71.</p>
<p>(I am using Visual Studio .NET 2003 to build ruby.)</p>
<p>Regards,</p>
<p>Bill<br>
=end</p> Ruby master - Bug #1685 (Closed): Some windows unicode path issues remainhttps://bugs.ruby-lang.org/issues/16852009-06-24T19:36:10Zspatulasnout (B Kelly)billk@cts.com
<p>=begin<br>
Hi,</p>
<p>I see some nice progress has been made in unicode path<br>
handling on windows.</p>
<p>The following tests are not exhaustive, but do reveal some<br>
remaining issues.</p>
<p>Everything below "NOT WORKING" fails in one way or another.</p>
<p>Regards,</p>
<p>Bill</p>
<pre><code># encoding: UTF-8
# Test unicode path/dir handling on windows
require 'test/unit'
class TestUnicodeFilenamesAndPaths < Test::Unit::TestCase
def setup
tmpdir = ENV['TEMP'] || "C:/TEMP"
Dir.chdir tmpdir
puts Dir.pwd
testdir = "ruby_unicode_test"
Dir.mkdir testdir unless test ?d, testdir
Dir.chdir testdir
puts Dir.pwd
end
def test_unicode_paths
fname_resume = "R\xC3\xA9sum\xC3\xA9".force_encoding("UTF-8")
fname_chinese = "\u52ec\u52ee\u52f1\u52f2.txt"
dname_chinese = "\u52ec\u52ee\u52f1\u52f2"
assert_equal( "UTF-8", fname_resume.encoding.name )
File.open(fname_resume, "w") {|io| io.puts "Hello, World"}
assert_equal( "UTF-8", fname_chinese.encoding.name )
File.open(fname_chinese, "w") {|io| io.puts "Hello, World"}
dat = File.read(fname_chinese)
assert_equal( "Hello, World\n", dat )
files = Dir["*"]
assert( files.include? fname_resume )
assert( files.include? fname_chinese )
# NOT WORKING:
Dir.rmdir dname_chinese rescue nil
Dir.mkdir dname_chinese
test ?d, dname_chinese
Dir.chdir dname_chinese
cwd = Dir.pwd
assert( cwd[(-dname_chinese.length)..-1] == dname_chinese )
Dir.chdir ".."
x = File.stat(fname_resume)
x = File.stat(fname_chinese)
x = File.stat(dname_chinese)
assert( File.exist? fname_resume )
assert( File.exist? fname_chinese )
assert( test(?f, fname_resume) )
assert( test(?f, fname_chinese) )
files = Dir[fname_resume]
assert_equal( fname_resume, files.first )
files = Dir[fname_chinese]
assert_equal( fname_chinese, files.first )
files = Dir[dname_chinese]
assert_equal( dname_chinese, files.first )
end
end
=end
</code></pre> Ruby master - Bug #1368 (Closed): ruby19 trunk (svn revision 23160) build fails compiling dl ext ...https://bugs.ruby-lang.org/issues/13682009-04-09T09:04:13Zspatulasnout (B Kelly)billk@cts.com
<p>=begin<br>
Hi,</p>
<p>In attempting to build from the current svn trunk (revision 23160)<br>
on win32, I'm getting a failure linking the dl extension.</p>
<p>(Building on WinXP, Visual Studio 2003, cl.exe version 13.10.6030)</p>
<p>I configured as follows:</p>
<p>win32\configure.bat --prefix=m:/dev/ruby-build/trunk --program-suffix=19<br>
nmake</p>
<p>The error was:</p>
<p>compiling dl<br>
cl -nologo -LD -Fe../../.ext/i386-mswin32_71/dl.so callback-0.obj callback-1.obj<br>
callback-2.obj callback-3.obj callback-4.obj callback-5.obj callback-6.obj<br>
callback-7.obj callback-8.obj cfunc.obj cptr.obj dl.obj handle.obj<br>
msvcr71-ruby19191.lib unicows.lib oldnames.lib user32.lib advapi32.lib shell32.lib<br>
ws2_32.lib -link -incremental:no -debug -opt:ref -opt:icf -incremental:no -debug<br>
-opt:ref -opt:icf -dll -libpath:"." -libpath:"../.." -implib:dl-i386-mswin32_71.lib<br>
-pdb:dl-i386-mswin32_71.pdb -def:dl-i386-mswin32_71.def<br>
LINK : fatal error LNK1181: cannot open input file 'callback-0.obj'</p>
<p>I experimented by entering the ext/dl/callback directory and manually<br>
running mkcallback.rb and extconf.rb and moving the resulting<br>
callback-*.obj to the ext/dl directory... But then I get different<br>
link errors:</p>
<pre><code>Creating library dl-i386-mswin32_71.lib and object dl-i386-mswin32_71.exp
</code></pre>
<p>callback-8.obj : error LNK2001: unresolved external symbol _rb_DLStdcallCallbackAddrs<br>
callback-4.obj : error LNK2001: unresolved external symbol _rb_DLStdcallCallbackAddrs<br>
callback-5.obj : error LNK2001: unresolved external symbol _rb_DLStdcallCallbackAddrs<br>
callback-6.obj : error LNK2001: unresolved external symbol _rb_DLStdcallCallbackAddrs<br>
callback-7.obj : error LNK2001: unresolved external symbol _rb_DLStdcallCallbackAddrs<br>
callback-0.obj : error LNK2001: unresolved external symbol _rb_DLStdcallCallbackAddrs<br>
callback-1.obj : error LNK2001: unresolved external symbol _rb_DLStdcallCallbackAddrs<br>
callback-2.obj : error LNK2001: unresolved external symbol _rb_DLStdcallCallbackAddrs<br>
callback-3.obj : error LNK2001: unresolved external symbol _rb_DLStdcallCallbackAddrs</p>
<p>etc.</p>
<p>So I'm a little lost at this point.</p>
<p>Hope this helps,</p>
<p>Bill<br>
=end</p> Backport187 - Backport #1223 (Closed): Memory leak reintroduced in 1.8.6 branch?https://bugs.ruby-lang.org/issues/12232009-02-28T09:34:06Zspatulasnout (B Kelly)billk@cts.com
<p>=begin<br>
In early 2008, there were some 1.8.6 versions prior to p279 which exhibited severe memory leaks. See:</p>
<p><a href="https://blade.ruby-lang.org/ruby-core/17613">[ruby-core:17613]</a> Re: [Ruby 1.8 - Bug <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Memory leaks in 1.8.6p230 and p238 (Closed)" href="https://bugs.ruby-lang.org/issues/216">#216</a>] Memory leaks in 1.8.6p230 and p238</p>
<p>I say "prior to p279" because p279 happens to be the version I have been using since then which has had an extremely stable memory profile.</p>
<p>This morning when upgrading a server I also tried upgrading ruby 1.8.6 from p279 to the current p355.</p>
<p>The server has about 200 long running ruby processes, which on p279 can run for months with a stable memory profile.</p>
<p>After switching to p355 I could watch the memory drain away in real-time. I started with over 1GB free, and finally killed them when it got down to about 65M free. These are values from the "+/- buffers/cache" line from the <code>free</code> command in linux, printed at 5 second intervals, right before I killed the processes:</p>
<pre><code> used free
3959084 104360
3963336 100108
3969248 94196
3974132 89312
3977016 86428
3981824 81620
3983472 79972
3988388 75056
3991796 71648
3994120 69324
3996916 66528
3997432 66012
</code></pre>
<p>After I swapped the old p279 binaries back in (libruby.so.1.8.6, libruby-static.a), the memory usage is once again stable.</p>
<p>Here are the svn revision numbers for the p279 vs. p355 builds I was using:</p>
<p>svn revision 19759 - ruby 1.8.6 (2008-07-17 patchlevel 279) [x86_64-linux]</p>
<p>svn revision 22671 - ruby 1.8.6 (2009-02-25 patchlevel 355) [x86_64-linux]</p>
<p>Regards,<br>
=end</p>