| Summary: | please stabilise dev-lang/ruby-1.8.6-r1 (and dev-ruby/cgi_multipart_eof_fix-2.1 where keyworded) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Richard Brown (RETIRED) <rbrown> |
| Component: | New packages | Assignee: | Gentoo Ruby Team <ruby> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | bugs+gentoo, ferdy, ferringb, fmccor, hanno, jakub, kingtaco, m.langer798, mips, ppc64, sgtphou, sparc |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
example code of memory leak
same example code with Mutex converted to Sync |
||
|
Description
Richard Brown (RETIRED)
2007-06-06 18:37:08 UTC
ppc64 done *** Bug 178346 has been marked as a duplicate of this bug. *** dev-ruby/cgi_multipart_eof_fix-2.1 needs stabling with this too, otherwise they'll block each other for eternity. dev-ruby/rake-0.7.2 (or newer) is on the same league too. ppc64 get your ass back here ;-) thanks, fixed (ppc64). sparc stable. dev-lang/ruby-1.8.6-r1 USE="examples ipv6 rubytests threads -debug -doc -socks5 -tk" 1. emerges on x86 2. passes collision test 3. result of the test suite: 1614 tests, 16610 assertions, 0 failures, 0 errors dev-ruby/cgi_multipart_eof_fix-2.1 USE="-doc" 1. emerges on x86 2. passes collision test dev-ruby/rake-0.7.2 USE="-doc" 1. emerges 2. passes collision test Portage 2.1.2.7 (default-linux/x86/2007.0/desktop, gcc-4.1.2, glibc-2.5-r3, 2.6.20.12 i686) ================================================================= System uname: 2.6.20.12 i686 Genuine Intel(R) CPU T2300 @ 1.66GHz Gentoo Base System release 1.12.9 Timestamp of tree: Sat, 09 Jun 2007 09:00:01 +0000 dev-java/java-config: 1.3.7, 2.0.32 dev-lang/python: 2.3.5-r3, 2.4.4-r4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=prescott -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -march=prescott -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--nospinner" FEATURES="collision-protect distlocks metadata-transfer parallel-fetch sandbox sfperms strict test userfetch userpriv usersandbox" GENTOO_MIRRORS="http://mirror.switch.ch/mirror/gentoo/ http://gentoo.inode.at/" LINGUAS="en de en_GB de_CH" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi alsa apache2 asf avahi berkdb bitmap-fonts cairo cdr cdrom cli cracklib crypt cups dbus divx dri dts dvd dvdr dvdread eds emboss encode evo fam ffmpeg firefox flac fortran gdbm gif gnome gpm gstreamer gtk hal iconv ipv6 isdnlog java jpeg kde kdeenablefinal kerberos ldap libg++ mad midi mikmod mmx mono mp3 mpeg mudflap ncurses nls nptl nptlonly ogg opengl openmp oss pam pcre pdf perl png pppd python qt3 qt3support qt4 quicktime readline reflection rtsp ruby samba sdl session smp spell spl sse sse2 sse3 ssl svg tcpd test tetex theora threads tiff truetype truetype-fonts type1-fonts unicode vcd vorbis wifi win32codecs wxwindows x264 x86 xine xml xorg xprint xv xvid zlib" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LINGUAS="en de en_GB de_CH" USERLAND="GNU" VIDEO_CARDS="i810 fbdev vesa" Unset: CTARGET, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY alpha/ia64/x86 stable, thanks Markus Stable for HPPA. stable on ppc mips stable. ====amd64==== Passes all tests. Running a few of my custom scripts still works. Portage 2.1.2.7 (default-linux/amd64/2007.0, gcc-4.1.2, glibc-2.5-r3, 2.6.20-gentoo-r7 x86_64) ================================================================= System uname: 2.6.20-gentoo-r7 x86_64 unknown Gentoo Base System release 1.12.9 Timestamp of tree: Wed, 13 Jun 2007 22:30:01 +0000 dev-lang/python: 2.4.4-r4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O1 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=athlon64 -O1 -pipe" DISTDIR="/distfiles" FEATURES="collision-protect distlocks metadata-transfer multilib-strict sandbox sfperms strict test" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://192.168.1.201/gentoo-portage" USE="X acl aiglx aim amd64 berkdb bitmap-fonts branding cli cracklib crypt cups dri fortran gdbm gpm gtk iconv imap ipv6 isdnlog libg++ midi mmx mpeg3 mudflap ncurses nls nptl nptlonly nvidia opengl openmp pam pcre perl pppd python qt3 readline reflection session sockets spl sqlite3 sse sse2 ssl tcpd test truetype-fonts type1-fonts unicode vim xcomposite xine xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY amd64 done, thanks Thomas (In reply to comment #3) > dev-ruby/cgi_multipart_eof_fix-2.1 needs stabling with this too, otherwise > they'll block each other for eternity. Re-adding amd64 and ppc wrt the above. :) amd64 done again :p (In reply to comment #13) > (In reply to comment #3) > > dev-ruby/cgi_multipart_eof_fix-2.1 needs stabling with this too, otherwise > > they'll block each other for eternity. > > Re-adding amd64 and ppc wrt the above. :) ppc stable *** Bug 182234 has been marked as a duplicate of this bug. *** (In reply to comment #3) > dev-ruby/rake-0.7.2 (or newer) is on the same league too. amd64 - I hate to CC you again, but... stabilize 0.7.3 please. :) rake-0.7.3 stable too, anything else to do before I remove us from CC again? :P I'll take that as a no FYI, we use ruby in our office. tried out 1.8.6 and it leaked 2G of memory in about 5 minutes(where 1.8.5-p2 doesnt) completely unsuitable for production or stable IMO. (In reply to comment #20) > FYI, we use ruby in our office. tried out 1.8.6 and it leaked 2G of memory in > about 5 minutes(where 1.8.5-p2 doesnt) completely unsuitable for production or > stable IMO. > Thanks for that detailed bug description. Your example code explaining how to reproduce the problem, along with the 'emerge --info' output you provided, have been very useful in helping us track down the problem. One question, though -- was this on an embedded sparc opteron? No-one else seems to be able reproduce the issue. (In reply to comment #21) > (In reply to comment #20) > > FYI, we use ruby in our office. tried out 1.8.6 and it leaked 2G of memory in > > about 5 minutes(where 1.8.5-p2 doesnt) completely unsuitable for production or > > stable IMO. > > > > Thanks for that detailed bug description. Your example code explaining how to > reproduce the problem, along with the 'emerge --info' output you provided, have > been very useful in helping us track down the problem. One question, though -- > was this on an embedded sparc opteron? No-one else seems to be able reproduce > the issue. > no test code, unless you find a way to be hired by my company(and with your awful attitude, that will never happen) which is why I didn't file a bug. Still, In MY Opinion, 1.8.6-r1 isn't stable or production ready. I'm confident you'll get other reports of memory leaks once people start using this. > > > FYI, we use ruby in our office. tried out 1.8.6 and it leaked 2G of memory in > > > about 5 minutes(where 1.8.5-p2 doesnt) completely unsuitable for production or > > > stable IMO. > no test code, unless you find a way to be hired by my company(and with your > awful attitude, that will never happen) which is why I didn't file a bug. > Still, In MY Opinion, 1.8.6-r1 isn't stable or production ready. > I'm confident you'll get other reports of memory leaks once people start using > this. Dear arches, sorry to mess you around. Kingtaco has informed me that this version of ruby has a 2GB memory leak, and is not suitable for stable. I've checked the ChangeLog of ruby-1.8.6_p36-r2, and don't see any fixes for memory leaks, so don't have a fix to backport. Please mark this ebuild at least ~arch for all your arches, perhaps even -arch, as ruby must be pretty much useless on any arch this affects. Once the ebuild is reduced to ~ or less I'll remove it from the tree. Please accept my apologies for downgrading your users, but I think that's better than giving them a known buggy version of ruby. Sorry for wasting your time getting you to test and stabilize this package, I will of course be asking kingtaco to say yes or no to any package I maintain before I accidentaly inflict a buggy version on our users. alpha/ia64/x86 done sparc will stay stable unless some other people vouch on this bug (or open a bug wrt to the leak). It's been stable for 2 weeks already without issues for us and the "bug" lacks any class of details. amd64 done (In reply to comment #25) > sparc will stay stable unless some other people vouch on this bug (or open a > bug wrt to the leak). > It's been stable for 2 weeks already without issues for us and the "bug" lacks > any class of details. > On sparc with a rather short test case (but one which creates and destroys lots of objects --- it's a discrete event simulation of a grocery store --- I can't tell any difference between memory usage for -1.8.6_p36-r2 and for -1.8.5_p2-r1. Now, both of them end up using about 200MB of dynamic memory, but I don't recall if that's unexpected or not. This does not increase over time as best as I can see. Alpha stable. If Mike wants to make a bug report, he can do so and provide the details and ways to reproduce it. Until then, it is all vapor. - ferdy http://rafb.net/p/MlgUrR16.txt This is a modified testcase that shows a memory leak. on my systems, 1.8.5_p2-r1 ping pongs but slowly seems to leak, where 1.8.6-r1 doesn't pingpong but just leaks. This is the emerge --info from my 1.8.6-r1 box: Portage 2.1.2.7 (default-linux/amd64/2006.1/desktop, gcc-4.1.2, glibc-2.5-r2, 2.6.20-gentoo-r5 x86_64) ================================================================= System uname: 2.6.20-gentoo-r5 x86_64 Dual Core AMD Opteron(tm) Processor 170 Gentoo Base System release 1.12.10 Timestamp of tree: Fri, 25 May 2007 20:00:01 +0000 dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.4.4-r4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.23b virtual/os-headers: 2.6.21 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=opteron -O2 -pipe -fomit-frame-pointer -msse3" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=opteron -O2 -pipe -fomit-frame-pointer -msse3" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LINGUAS="en en_US" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X alsa amd64 bash-completion berkdb bitmap-fonts cairo cdr cli cracklib crypt cups dri dvd dvdr eds emacs emboss encode fam firefox fortran gdbm gif gpm gstreamer gtk gtk2 iconv ipv6 isdnlog jpeg libg++ mad midi mikmod mp3 mpeg mudflap ncurses nls nptl nptlonly offensive ogg opengl openmp pam pcre pdf perl png ppds pppd python quicktime readline reflection sdl session spell spl sse3 ssl tcpd truetype truetype-fonts type1-fonts unicode vorbis xml xorg xv zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="evdev keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en en_US" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS readding myself (In reply to comment #29) > http://rafb.net/p/MlgUrR16.txt Don't rafb pastes expire after a few days? Created attachment 122737 [details]
example code of memory leak
this is the same file I posted on rafb.net (in response to ciaranm)
(In reply to comment #20) > FYI, we use ruby in our office. tried out 1.8.6 and it leaked 2G of memory in > about 5 minutes(where 1.8.5-p2 doesnt) completely unsuitable for production or > stable IMO. Hmm, it started at 3.9% of my 1 gig of RAM on this laptop and stayed at the very exact 3.9% after 7 minutes run, then I got bored and killed it... Then I disassambled the box and didn't spot any new memory sticks in there, at which point I got very disappointed. (In reply to comment #33) > (In reply to comment #20) > > FYI, we use ruby in our office. tried out 1.8.6 and it leaked 2G of memory in > > about 5 minutes(where 1.8.5-p2 doesnt) completely unsuitable for production or > > stable IMO. > > Hmm, it started at 3.9% of my 1 gig of RAM on this laptop and stayed at the > very exact 3.9% after 7 minutes run, then I got bored and killed it... Then I > disassambled the box and didn't spot any new memory sticks in there, at which > point I got very disappointed. > maybe you could post details of your install so your post is of some use and not just a troll like you do on most of the other bugs. (In reply to comment #34) > maybe you could post details of your install so your post is of some use and > not just a troll like you do on most of the other bugs. Well, maybe you could post a working testcase instead, now that you've forced a pointless downgrade on lots of arches? Not reproducible on either of these: Portage 2.1.3_rc4 (default-linux/amd64/2007.0/desktop, gcc-4.1.2, glibc-2.5-r3, 2.6.21-gentoo-r3 x86_64) ================================================================= System uname: 2.6.21-gentoo-r3 x86_64 AMD Turion(tm) 64 Mobile Technology MT-32 [ebuild R ] dev-lang/ruby-1.8.6-r1 USE="-debug -doc -examples -ipv6 -rubytests -socks5 threads -tk" 0 kB Portage 2.1.3_rc4 (default-linux/x86/2007.0/desktop, gcc-4.1.2, glibc-2.5-r3, 2.6.21-gentoo-r3 i686) ================================================================= System uname: 2.6.21-gentoo-r3 i686 AMD Athlon(tm) XP 1600+ [ebuild R ] dev-lang/ruby-1.8.6_p36-r2 USE="-cjk -debug -doc -examples ipv6 -rubytests -socks5 threads -tk" 0 kB (In reply to comment #35) > System uname: 2.6.21-gentoo-r3 x86_64 AMD Turion(tm) 64 Mobile Technology > MT-32 <snip> > System uname: 2.6.21-gentoo-r3 i686 AMD Athlon(tm) XP 1600+ I'm assuming both are single core? Asking since I'm seeing a growing leak on my duo core, and tacos was dual amd64... (In reply to comment #36) > I'm assuming both are single core? Correct. I tried 1.8.6-r1 on my single core x86 laptop (2007.0/desktop profile) and the leak is less, but still present. jakub: you're the first to post that you don't leak memory. could you recompile ruby with USE=-threads and try running the test for 20+ minutes? watch the RES field in top for memory usage. (In reply to comment #39) > jakub: you're the first to post that you don't leak memory. could you > recompile ruby with USE=-threads and try running the test for 20+ minutes? > watch the RES field in top for memory usage. > No, see Comment 27, Comment 25. Prod me and I'll try your test case on sparc tomorrow on sparc. My test was not (ruby-)threaded. (In reply to comment #40) > (In reply to comment #39) > > jakub: you're the first to post that you don't leak memory. could you > > recompile ruby with USE=-threads and try running the test for 20+ minutes? > > watch the RES field in top for memory usage. > > > > No, see Comment 27, Comment 25. Prod me and I'll try your test case on sparc > tomorrow on sparc. My test was not (ruby-)threaded. > You didn't have the test case until comment 29. while the tests you ran may have been valid, they didn't test this specific memory leak. One of my programmers changed the Mutex objects to Sync objects and memory usage is stable on 1.8.6_p36-r2, similar to the mongrel ML message someone posted to me today(http://rubyforge.org/pipermail/mongrel-users/2006-August/001239.html) I'll do some more testing tomorrow. Also, we can confirm that drb uses the Mutex class which is what we think is causing the memory leak. If all this is true, 1.8.6 is no less stable than 1.8.5 and shouldn't be a blocker to keywording it(1.8.5_p2-r1 isn't any more stable than 1.8.6-r1) Created attachment 122767 [details]
same example code with Mutex converted to Sync
this one appears to not leak memory
(In reply to comment #39) > could you recompile ruby with USE=-threads and try running the test for 20+ > minutes? watch the RES field in top for memory usage. Well, this would takes ages to get anywhere near to the 2GB... started at ~31M, doesn't look like USE="-threads" would change much here except that it uses slightly more memory in general. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2063 jakub 25 0 38952 35m 2004 R 67.0 4.7 20:37.55 ruby [ebuild R ] dev-lang/ruby-1.8.6-r1 USE="-debug -doc -examples -ipv6 -rubytests -socks5 -threads -tk" 0 kB This is upstream bug http://rubyforge.org/tracker/index.php?func=detail&aid=11558&group_id=426&atid=1698 I've added the test case and described the link with drb.rb and hence the urgency for real-world use. @kingtaco: I'm glad I passed you that link on IRC yesterday. :-) On sparc, with the original example, there is a memory leak, but pretty slow: It would take us forever to get anyplace like 2 GB: After 13 minutes, we see:
===============================================
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
17611 fmccor 25 0 40608 36m 2608 R 100 1.8 13:00.03 ruby
(At startup, this was)
17638 fmccor 25 0 35120 30m 2608 R 99 1.5 0:03.21 ruby
================================================
The example using sync goes like this:
At start,
=================================================
17641 fmccor 25 0 63024 58m 2592 R 100 2.9 0:18.14 ruby
It grows memory usage like this:
=================================================
17641 fmccor 25 0 65904 61m 2608 R 100 3.0 5:33.72 ruby
But then it bounces back down to 59m and cycles, so there does not appear to be a leak.
This is on SB1000 (1x900+1x750)MP system, using:
polylepis ~ # eix dev-lang/ruby
[I] dev-lang/ruby
Available versions: (1.8) 1.8.4-r3 1.8.5_p2 1.8.5_p2-r1 (~)1.8.5_p12 (~)1.8.5_p35 1.8.6-r1 (~)1.8.6_p36-r1 (~)1.8.6_p36-r2
Installed versions: 1.8.6_p36-r2(1.8)(06:24:15 PM 06/21/2007)(-cjk -debug -doc examples -ipv6 -rubytests -socks5 -threads tk)
================================================
Adding sparc for information purposes.
================================================
Now, for comparison, same system, ruby-1.8.5_p2-r1:
The leak-with-thread example starts here:
==================================================
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
18392 fmccor 25 0 40600 36m 2568 R 99 1.8 0:11.97 ruby
.................
18392 fmccor 21 0 47160 42m 2568 R 100 2.1 16:05.45 ruby
So for me, it is actually growing faster.
Now, the sync version, also ruby-1.8.5_p2-r1
================================================
18424 fmccor 25 0 65640 60m 2552 R 100 3.0 0:27.59 ruby
.........................
18424 fmccor 25 0 63576 58m 2568 R 100 2.9 10:27.91 ruby
(With this version of ruby, RES bounces between 58m and 63m)
So, on sparc, it looks as if with 1.8.6 (_p36-r2), ruby has been modified to be more memory efficient with ruby-threads, but there does seem to be a slow memory leak as well. It looks to me, though, that there is already a memory leak with threads on 1.8.5_p2-r1.
Using Sync instead of Mutex seems to be generally more expensive initially, but I don't see a leak with any version of ruby. (I note, however, that the Sync version and Mutex version produce quite different output, whether or not this matters in an actual application, I cannot say.)
You're assuming that when GC.start is called, Ruby guarantees to free all unused memory. I can't find any such guarantee documented -- merely the claim that calling GC.start will start garbage collection, which doesn't mean the garbage collector will free everything it can. (In reply to comment #47) > You're assuming that when GC.start is called, Ruby guarantees to free all > unused memory. I can't find any such guarantee documented -- merely the claim > that calling GC.start will start garbage collection, which doesn't mean the > garbage collector will free everything it can. > I don't think anyone makes that assumption. that call was in the code I based mine off of. either way, it doesn't matter, it's still a bug. I think the likelyhood of a bug in a interpeted languages threading library(think python) is higher than in the garbage collector which probably receives much more testing. I'll keep mips on stable for now. I don't know how often Ruby is used on our arch, let alone how many of those potential users are using Mutex-based calls of the type needed to trigger this bug (assuming I've followed the discussion here correctly), so I think that, for us, it's a corner case and a non-issue. The odds are that this bug will get fixed upstream before anyone files a bug to us that gets dupe'ed to this bug. Keeping mips on CC too, just to follow. no news for two months. Add us back when ppc needs to do something here. can this be closed in favour of bug 194236? *** This bug has been marked as a duplicate of bug 194236 *** |
