Date: Tue, 5 Jun 2012 12:26:21 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Stanislav Sedov <stas@freebsd.org> Cc: ports@freebsd.org, Steve Wills <swills@freebsd.org>, ruby@freebsd.org Subject: Re: Ruby 1.9 as default Message-ID: <20120605092621.GJ85127@deviant.kiev.zoral.com.ua> In-Reply-To: <07758721-BD54-4732-9B17-83D4CCCF55E0@freebsd.org> References: <4FC96D45.8080904@FreeBSD.org> <20120601193059.af9201da.stas@FreeBSD.org> <4FCD51E4.4030309@FreeBSD.org> <20120605085202.GI85127@deviant.kiev.zoral.com.ua> <07758721-BD54-4732-9B17-83D4CCCF55E0@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--fKov5AqTsvseSZ0Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 05, 2012 at 02:04:33AM -0700, Stanislav Sedov wrote: >=20 > On Jun 5, 2012, at 1:52 AM, Konstantin Belousov wrote: >=20 > > On Mon, Jun 04, 2012 at 08:25:08PM -0400, Steve Wills wrote: > >> On 06/01/12 22:30, Stanislav Sedov wrote: > >>>=20 > >>> I'm not sure it's a good idea. > >>> Ruby 1.9 still has some nasty bugs on FreeBSD, related to the threads= and > >>> fork. That is fork in ruby 1.9 hangs sometimes... > >>=20 > >> The ONLY thing I can find is this: > >>=20 > >> http://bugs.ruby-lang.org/issues/2097 > >>=20 > >> which implies that it's fixed. If there's more to this issue than > >> "broken on 7.3 and earlier", PLEASE let me know. > >=20 > > If ruby indeed does what the bugs described, that is, calls non-async > > signal safe functions from the threaded process after fork, then you > > are guaranteed to get random hangs sometimes. >=20 > Actually, the problem I'm trying to debug right now is more weird. > When I run mono via system(3) from the ruby 1.9 process (I mean, > exactly system(3), not via some ruby wrapper) twice, it hangs on some > umtx the second time. This works all the time. >=20 > I'm still trying to track it down in mono, though it's not clear how > this can happen at all. Isn't execve(2) used by system(3) is supposed > to clear everything (mutexes at least)? The address space of the exec-ed process is completely reset, but the full process state is not. Most often, the problematic bits are the ignored signals, which are inherited. Please note that 'umtx hangs' are not system problems most often, but indicate an application bug. If program has multithreading bug that results in threads deadlock, you end up with threads in some umtx sleep state. Sorry, I cannot give any further advise except the hand-waving above. --fKov5AqTsvseSZ0Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/N0LwACgkQC3+MBN1Mb4h/ZgCgoC+BrHOBIiTLuQrDMl2OTsN3 SBcAoK6VbY2pzGyTe/ZSSl/X7HwyckSR =FVi9 -----END PGP SIGNATURE----- --fKov5AqTsvseSZ0Z--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120605092621.GJ85127>