Bug #19169 for IPC-Shareable: Make test locks up at t/38ipchv

Tue May 09 16:13:04 2006 Guest - Ticket created

Subject:

Make test locks up at t/38ipchv

What can I say? ... t/15hv........ok t/20ref.......ok t/25ipc.......ok t/30lock......ok t/35clean.....ok t/36ipcav.....ok t/38ipchv.....ok 1/5 (hang) This is on Fedora Core 5, i386, kernel 2.6.16-1.2111_FC5.

Thu Sep 06 10:57:57 2007 matt [...] bodgit-n-scarper.com - Correspondence added

From:

matt [...] bodgit-n-scarper.com

On Tue May 09 16:13:04 2006, guest wrote: Show quoted text

> What can I say? > > ... > t/15hv........ok > t/20ref.......ok > t/25ipc.......ok > t/30lock......ok > t/35clean.....ok > t/36ipcav.....ok > t/38ipchv.....ok 1/5 (hang) > > This is on Fedora Core 5, i386, kernel 2.6.16-1.2111_FC5.

Just a bump on this. I can trigger this fairly reliably on either CentOS 5 x86_64 or Fedora 7 i386.

Thu Sep 06 10:58:02 2007 The RT System itself - Status changed from 'new' to 'open'

Wed Dec 19 08:52:21 2007 TONVOON [...] cpan.org - Correspondence added

From:

TONVOON [...] cpan.org

I've found this is a problem with the speed of response to a kill ALRM. The parent must be sending the ALRM signal so quickly that the child doesn't get to process it soon enough. My fix was to add a sleep 1 after the first ALRM. I now get consistent passes for this test. diff -ur IPC-Shareable-0.60.original/t/38ipchv.t IPC-Shareable-0.60/t/38ipchv.t --- IPC-Shareable-0.60.original/t/38ipchv.t 2001-01-11 15:49:13.000000000 +0000 +++ IPC-Shareable-0.60/t/38ipchv.t 2007-12-19 13:42:53.000000000 +0000 @@ -70,6 +70,7 @@ }); %hv = (); kill ALRM => $pid; + sleep 1; # Allow time for child to process the signal before next ALRM comes in for (qw(eenie meenie minie moe)) { $ipch->shlock();

Tue Oct 09 01:44:32 2012 msouth [...] gmail.com - Correspondence added

On Wed Dec 19 08:52:21 2007, TONVOON wrote: Show quoted text

> I've found this is a problem with the speed of response to a kill > ALRM. The parent must be > sending the ALRM signal so quickly that the child doesn't get to > process it soon enough. My > fix was to add a sleep 1 after the first ALRM. > > I now get consistent passes for this test. > > diff -ur IPC-Shareable-0.60.original/t/38ipchv.t IPC-Shareable- > 0.60/t/38ipchv.t > --- IPC-Shareable-0.60.original/t/38ipchv.t 2001-01-11 > 15:49:13.000000000 +0000 > +++ IPC-Shareable-0.60/t/38ipchv.t 2007-12-19 13:42:53.000000000 > +0000 > @@ -70,6 +70,7 @@ > }); > %hv = (); > kill ALRM => $pid; > + sleep 1; # Allow time for child to process the signal > before next ALRM comes in > > for (qw(eenie meenie minie moe)) { > $ipch->shlock(); > >

I applied this patch, can someone who can reproduce the problem test with https://github.com/msouth/IPC-Shareable.git and make sure it fixes it? I hate to release a change without a confirmation.

Sat Oct 13 00:09:52 2012 msouth [...] gmail.com - Correspondence added

RT-Send-CC:

TONVOON [...] cpan.org, matt [...] bodgit-n-scarper.com

I put the sleep 1 fix for this in 0.61. If either of you could test it would be appreciated.

Sat Oct 13 00:09:53 2012 msouth [...] gmail.com - Status changed from 'open' to 'resolved'

Mon Oct 15 03:46:25 2012 TONVOON [...] cpan.org - Correspondence added

On Sat Oct 13 00:09:52 2012, MSOUTH wrote: Show quoted text

> I put the sleep 1 fix for this in 0.61. If either of you could test > it would be appreciated.

Hi! I can't reproduce at the moment, but as I suggested the fix, I'm sure it is okay! All tests pass for me with 0.61. Ton

Mon Oct 15 03:46:26 2012 The RT System itself - Status changed from 'resolved' to 'open'

Mon Oct 05 17:12:50 2015 msouth [...] gmail.com - Correspondence added

Marking this resolved, as far as we know, it is.

Mon Oct 05 17:12:56 2015 msouth [...] gmail.com - Status changed from 'open' to 'resolved'

Mon Oct 05 17:12:57 2015 msouth [...] gmail.com - Fixed in 0.61 added