Synced:
ruby1.8 (1.8.7.249-2) unstable; urgency=low
* Add 100312_timeout-fix.dpatch: Backport upstream change to fix
problem with threads and timeouts. Closes: #539987
-- Lucas Nussbaum lu...@lucas-nussbaum.net Fri, 12 Mar 2010 07:13:47
+0100
** Changed in: ruby-defaults (Ubuntu Lucid)
After investigation it is not a glibc bug.
** Changed in: eglibc (Ubuntu Lucid)
Status: Triaged = Invalid
--
building ruby1.8 with pthread support causes puppet hangs
https://bugs.launchpad.net/bugs/520715
You received this bug notification because you are a member of Ubuntu
Bugs, which
Fixed package just uploaded to Debian, ruby1.8 1.8.7.249-2. Will ask for
a sync as soon as it is in the Debian archive.
--
building ruby1.8 with pthread support causes puppet hangs
https://bugs.launchpad.net/bugs/520715
You received this bug notification because you are a member of Ubuntu
Bugs,
Are we even sure pthreads is central to the issue?
I've been a bit flat out which is why I disappeared in this bug history,
but I'll see if I can get some more concrete info this week.
--
building ruby1.8 with pthread support causes puppet hangs
https://bugs.launchpad.net/bugs/520715
You
On 08/03/10 at 16:02 -, Nigel Kersten wrote:
Are we even sure pthreads is central to the issue?
I am quite sure that the way ruby plays with pthread is central to this
issue, yes. But it is not clear whether ruby triggers a glibc bug, or
whether the glibc triggers a ruby bug.
Note that
Guys,
anything todo to give you some hands?
I can support you regarding puppet, glibc, and hardware .. ( I know google has
more then I will ever have, but we have some nice blades which need something
to do...)
Furthermore puppet + ubuntu == our way to work
So, andrew, lucus, dokogive me
Well, a good start would be to reproduce the issue, analyze how ruby1.8
is using pthreads, and see if you can either produce a test case without
ruby (to be able to find a specific bug or change in eglibc), or
understand what ruby is doing with pthreads and fix it.
--
building ruby1.8 with
I'm trying to pick up the ball for Nigel because he's rather busy with
something else at the moment.
What Nigel was trying to say in comment #19, was that we're not seeing
the correct behaviour. i.e. the code was not working the way it is
supposed to. The thread is not getting killed when there
Some more data points. On the same machine, running Linux 2.6.32-3-amd64 (from
Debian)
- I cannot reproduce the problem from comment #13 in a sid chroot
- I can reproduce the problem in a lucid chroot
- I can reproduce the problem in a sid chroot, using the libc packages from
Debian experimental
upstream bug updated with that info.
--
building ruby1.8 with pthread support causes puppet hangs
https://bugs.launchpad.net/bugs/520715
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
Reassigning to eglibc and doko as directed by slangasek
** Package changed: ruby1.8 (Ubuntu Lucid) = eglibc (Ubuntu Lucid)
** Changed in: eglibc (Ubuntu Lucid)
Assignee: (unassigned) = Matthias Klose (doko)
--
building ruby1.8 with pthread support causes puppet hangs
On 18/02/10 at 06:51 -, Nigel Kersten wrote:
I had a quick look at Timeout. The problem is there in:
x = Thread.current
y = Thread.start {
sleep sec
x.raise exception, execution expired if x.alive?
}
and Thread x.status returns a sleep state even
Sorry, I wasn't clear again :)
I understand how the code works, I was pointing out that if something
this trivial isn't working there is something fundamental broken with
Thread.status, Thread.alive? etc.
--
building ruby1.8 with pthread support causes puppet hangs
Could you write a test case ? I'm still not sure I understand what you
are seeing.
--
building ruby1.8 with pthread support causes puppet hangs
https://bugs.launchpad.net/bugs/520715
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
On 16/02/10 at 23:10 -, Nigel Kersten wrote:
So this isn't a Puppet bug at all.
It looks to be a bug in the Ruby Timeout module that seems to be
triggered when most of your cores are busy.
Hi,
Just to clarify: how do you know it is the same problem?
I can reliably reproduce it by
Sorry, I should have made this clearer.
I work with Joel and Andrew, and am responsible for the Puppet
infrastructure here.
I spent a while debugging what was causing Facter and/or Puppet to hang,
and it all came down to the calls being wrapped in Timeout.
I did reproduce this on Debian Testing
PS. I'm open to the possibility libc is at fault. The patch Joel linked
to earlier:
http://svn.ruby-lang.org/cgi-
bin/viewvc.cgi/branches/ruby_1_8_7/eval.c?r1=23997r2=24104diff_format=l
worries me a little with line # 12319
--
building ruby1.8 with pthread support causes puppet hangs
On 17/02/10 at 17:45 -, Nigel Kersten wrote:
Sorry, I should have made this clearer.
I work with Joel and Andrew, and am responsible for the Puppet
infrastructure here.
I spent a while debugging what was causing Facter and/or Puppet to hang,
and it all came down to the calls being
I did verify the issue exists on the latest stock Lucid, but didn't dig
this deeply at the time I did that. It will be interesting to see
whether I get the same behavior pattern as Lucid + Google stuff or
Debian testing.
We'll get some more data in soon.
--
building ruby1.8 with pthread
I had a quick look at Timeout. The problem is there in:
x = Thread.current
y = Thread.start {
sleep sec
x.raise exception, execution expired if x.alive?
}
and Thread x.status returns a sleep state even after the test execs
complete, which seems pretty
So this isn't a Puppet bug at all.
It looks to be a bug in the Ruby Timeout module that seems to be
triggered when most of your cores are busy.
I can reliably reproduce it by firing up openssl speed (n-1) times where
n is the number of cores and then using the Timeout module.
#!/usr/bin/ruby1.8
It's really difficult to reproduce. Puppet hangs loading the facts,
before it ever gets down to any real business. The fact it consistently
hangs on is a custom one we've written. Furthermore, it only seems to
hang on some types of hardware, and not under strace.
Although that said, when Joel was
On 11/02/10 at 19:55 -, Joel Ebel wrote:
Puppet is hanging for us under Lucid with ruby1.8 1.8.7.249-1.
Could you provide a puppet snippet that causes this hang? I'd be
interested in how you are invoking puppet as well. I'm not currently
seeing this issue, but it seems to be a specific case,
Lucas, I'm going to work on a reproducible case that doesn't involve
Puppet at all.
I do believe Puppet is triggering a more fundamental problem, but agree
we need to clearly demonstrate this.
--
building ruby1.8 with pthread support causes puppet hangs
https://bugs.launchpad.net/bugs/520715
OK, let's try to summarize...
Facts, on --enable-pthread vs --disable-pthread:
- There's a noticeable performance gain with --disable-pthread, at least with
some benchmarks.
- Consequences of switching to --disable-pthread are unclear. Linking a
non-pthread ruby with a pthread tk doesn't work
It appears I was incorrect about Red Hat. However, the default ruby
build does not include pthreads, which had me confused for quite some
time why the debian package was failing while when I built ruby by hand
it worked fine.
Here's what I know:
Reasons to consider disabling pthreads:
- As you
On 12/02/10 at 19:55 -, Joel Ebel wrote:
- As you say, there are performance impacts of enabling pthreads,
particularly with puppet.
No. I said that there are performance impacts of enabling pthreads, at
least with some benchmarks. I didn't say anything about puppet.
- Pthreads causes
** Patch added: debdiff to disable building ruby1.8 with pthread support
http://launchpadlibrarian.net/39076585/ruby1.8_1.8.7.249-1ubuntu1.debdiff
--
building ruby1.8 with pthread support causes puppet hangs
https://bugs.launchpad.net/bugs/520715
You received this bug notification because
** Patch added: debdiff patch to ruby-defaults to disable tcl/tk packages and
remove recommendation of libtcltk-ruby1.8 by ruby-full
http://launchpadlibrarian.net/39076618/ruby-defaults_4.2ubuntu1.debdiff
** Also affects: ruby-defaults (Ubuntu)
Importance: Undecided
Status: New
--
Some of the issues with Ruby and pthreads were called out in
https://blueprints.launchpad.net/ubuntu/+spec/server-karmic-puppet-
integration
** Changed in: ruby1.8 (Ubuntu)
Status: New = Triaged
** Changed in: ruby-defaults (Ubuntu)
Status: New = Triaged
--
building ruby1.8 with
** Tags added: patch
--
building ruby1.8 with pthread support causes puppet hangs
https://bugs.launchpad.net/bugs/520715
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
** Also affects: ruby-defaults (Ubuntu Lucid)
Importance: Undecided
Status: Triaged
** Also affects: ruby1.8 (Ubuntu Lucid)
Importance: Undecided
Status: Triaged
--
building ruby1.8 with pthread support causes puppet hangs
https://bugs.launchpad.net/bugs/520715
You received
I don't have a test suite for other ruby libs, so no I can't say with
certainty that building them without pthreads doesn't break them, but
being the default for usptream ruby, and used by Red Hat leads me to
believe that ruby without pthreads has been pretty thoroughly tested
elsewhere.
I'm
On 12/02/10 at 00:00 -, Joel Ebel wrote:
I don't have a test suite for other ruby libs, so no I can't say with
certainty that building them without pthreads doesn't break them, but
being the default for usptream ruby, and used by Red Hat leads me to
believe that ruby without pthreads has
34 matches
Mail list logo
