t/pmc/nci.t still hangs on the threads branch on darwin/ppc

Sat Aug 4 19:40:33 UTC 2012

Sorry for TOP Posting. Im at Texas Linux Fest now.
With the new Powerbook G4 I could reproduce Jim's nci deadlock in the
threads branch

I did not gdb into it yet, I only did it --optimize'd as it's a very
slow machine.
These are the two threads at test 37:
Sampling process 36279 for 3 seconds with 1 millisecond of run time
between samples
Sampling completed, processing symbols...
Analysis of sampling parrot (pid 36279) every 1 millisecond
Call graph:
    2304 Thread_2503
      2304 start
        2304 main
          2304 Parrot_api_run_bytecode
            2304 Parrot_pf_execute_bytecode_program
              2304 Parrot_cx_begin_execution
                2304 Parrot_cx_outer_runloop
                  2304 Parrot_thread_wait_for_notification
                    2304 _pthread_cond_wait
                      2304 __semwait_signal
                        2304 __semwait_signal
    2304 Thread_2603
      2304 _pthread_start
        2304 Parrot_alarm_runloop
          2304 _pthread_cond_wait
            2304 __semwait_signal
              2304 __semwait_signal

Total number in stack (recursive counted multiple, when >=5):

Sort by top of stack, same collapsed (when >= 5):
        __semwait_signal        4608
Sample analysis of process 36279 written to file /dev/stdout

On Thu, Jul 26, 2012 at 11:02 AM, Reini Urban <rurban at x-ray.at> wrote:
> On Wed, Jul 25, 2012 at 9:20 PM, James E Keenan <jkeen at verizon.net> wrote:
>> On 7/21/12 6:15 AM, Stefan Seifert wrote:
>>>
>>> On Friday 20 July 2012 14:05:48 Jonathan Duke Leto wrote:
>>>
>>>> I dusted off my darwin/ppc box and the latest commit on the threads
>>>> branch still hangs on t/pmc/nci.t .
>>>>
>>>> If anybody has any ideas/patches that they would like me to try,
>>>> please let me know.
>>>
>>>
>>> Can you please try the attached patch? It just increases the timeouts in
>>> some
>>> tests. The original uses 10ms sleeps which is very little considering that
>>> for
>>> example Windows gives us only 100ms resolution timers. If this doesn't
>>> help,
>>> it's probably a problem with the timer thread.
>>>
>>
>> Unfortunately, in the threads branch this file hangs -- though the test it
>> hangs on may differ from run to run.
>>
>> Below:  the file hangs at test 37.
>>
>> $ prove -v t/pmc/nci.t
>> t/pmc/nci.t ..
>> 1..60
>> ok 1 - load library fails
>> ok 2 - dlfunc on undef
>> ok 3 - dlfunc function not found
>> ok 4 - dlfunc function is defined
>> ok 5 - dlfunc function pointer
>> ok 6 - nci_c - return a char in an INTEGER register
>> ok 7 - nci_d and nci_dlvar_double
>> ok 8 - nci_f and nci_dlvar_float
>> ok 9 - nci_l - return a long in an INTEGER register
>> ok 10 - nci_p - return a pointer to int
>> ok 11 - nci_s - return a short in an INTEGER register
>> ok 12 - nci_v and nci_dlvar_int
>> ok 13 - nci_dd - PASM
>> ok 14 - nci_dd - PIR
>> ok 15 - get_string()
>> ok 16 - nci_fff
>> ok 17 - nci_isc
>> ok 18 - nci_ssc
>> ok 19 - nci_csc
>> ok 20 - nci_dd - stress test
>> ok 21 - nci_dd - clone
>> ok 22 - nci_iiii
>> ok 23 - nci_pi - struct with ints
>> ok 24 - nci_pi - struct with floats
>> ok 25 - nci_pi - align
>> ok 26 - nci_pi - char*
>> ok 27 - nci_pi - nested struct *
>> ok 28 - nci_pi - nested struct * w named access
>> ok 29 - nci_pi - func_ptr* with signature
>> ok 30 - nci_pi - nested struct aligned
>> ok 31 - nci_pi - nested struct unaligned
>> ok 32 - nci_pi - nested, unaligned, named
>> ok 33 - nci_pi - int
>> ok 34 - nci_ip
>> ok 35 - nci_pi - null
>> not ok 36 - nci_vP # TODO Disabled to avoid linkage problems, see
>> src/nci_test.c
>>
>> #   Failed (TODO) test 'nci_vP'
>> #   at t/pmc/nci.t line 1292.
>> #          got: 'got null
>> # got null
>> # '
>> #     expected: 'ok
>> # got null
>> # '
>>
>> But on the next run, I got through test 37, only to experience a hang on
>> test 38:
>>
>> ok 37 - nci_cb_C1 - PASM
>>
>> And on the third run, I got through both 37 and 38, only to hang on 39:
>>
>> ok 37 - nci_cb_C1 - PASM
>> ok 38 - nci_cb_C1 - PIR
>>
>> But on the fourth run, I was back to hanging on 37.
>
> Now that's interesting. It indeed looks like a deadlock in nci
> callbacks when run in parallel.
> At first we should disallow those cb tests to run in parallel. And
> maybe skip 36 nci_vP.
> --
> Reini Urban
> http://cpanel.net/   http://www.perl-compiler.org/

-- 
Reini Urban
http://cpanel.net/   http://www.perl-compiler.org/