Andy Armstrong wrote:
On 8 Dec 2007, at 14:18, Andy Armstrong wrote:
Please let me know if there's anything you'd like me to investigate.
I'm afraid I don't know my way around parrot, er, at all - but I'm
willing to learn.
Ah, Mac OS 10.5 has dtrace - which I hadn't tried before but turns out
to be rather cool. Anyway, attaching to parrot once it's hung suggests
that it's deadlocked (I'd pretty much inferred that from the fact that
it's CPU load goes to zero and I'm sure you knew that anyway).
I have six threads
6 threads is surprising, you should have 4 (the central interpreter, the
I/O thread, the events thread, and the new concurrency scheduler
thread). The particular hanging test could have its own threads added.
What does the Mac OS "Activity Monitor" utility report for that process?
(Or, in general. Watch it through a test run and see how many threads it
reports for the parrot processes that flick by.)
- all waiting in __semwait_signal apart from one
whose call stack looks like
thread_start -> _pthread_start -> select$DARWIN_EXTSN
If that kind of information helps at all I can try to work out a little
more of what dtrace is actually doing.
That is useful. It's a pretty safe bet that the deadlocking resource is
the scheduler PMC, so the question becomes, where is the contention?
Especially in a test like t/pmc/parrotlibrary.t, which doesn't do
anything but instantiate one PMC.
Could you edit src/scheduler.c and change the value of CX_DEBUG to 1,
recompile, and run the test suite? Most of the tests will fail because
of the additional output on stderr, but if you can catch a hang, we'll
have a little more detail on what stage the scheduler was in when the
deadlock hit.
Allison
