Project

General

Profile

[logo] 
 
Home
News
Activity
About/Contact
Major Tools
  Dinotrace
  Verilator
  Verilog-mode
  Verilog-Perl
Other Tools
  IPC::Locker
  Parallel::Forker
  Voneline
General Info
  Papers

Issue #237

Returning multiple locks for a single request

Added by Krishna Subramanian almost 10 years ago. Updated almost 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
% Done:

0%


Description

I think I have found a potential bug. I am using version client/server version 1.484. Please find attached a the log file showing the output from the client. From the log, the bug becomes clear. When requesting for any one of a number of locks, two locks are returned instead of the first lock that is free or the first lock to become free. If you need more information, I may be able to provide other log information.

Thanks, Krishna

instance1.txt View - Bug instance 1 (2.4 KB) Krishna Subramanian, 04/07/2010 09:42 PM

History

#1 Updated by Wilson Snyder almost 10 years ago

  • Status changed from New to AskedReporter
  • Assignee set to Wilson Snyder

Sorry you're having problems. This code is fairly heavily tested, but...

Since I see two "RESP locked 1" that most likely means you're asking for the lock twice. That might be why there are two different locks returned - one for the first request and one for the second.

Can you send the client code?

Also unless I see something obvious I'm going to need the debug from the server too "lockerd --nofork --debug"

#2 Updated by Wilson Snyder almost 10 years ago

Reply:

Thanks for the reply. The server has not been modified. The client (IPC/Locker.pm) has been slightly modified. I am sending you the client and the code we use to request for locks from the server.

It would be hard for me to stop the server and re-run with the options you mention since it has been running in a production environment for quite some time. But if you are not able to debug using the code that I am sending, then I will try to run something separately. Obviously, finding such problems is rare and may or may not occur again.

Thanks, Krishna

#3 Updated by Wilson Snyder almost 10 years ago

Thanks for the reply. The server has not been modified. The client (IPC/Locker.pm) has been slightly modified. I am sending you the client and the code we use to request for locks from the server.

Great, I'll incorporate your changes (in a more general way) in the next release.

It would be hard for me to stop the server and re-run with the options you mention since it has been running in a production environment for quite some time. But if you are not able to debug using the code that I am sending, then I will try to run something separately. Obviously, finding such problems is rare and may or may not occur again.

Yup, that's one of the reasons I thought it was well tested. I realize now our application wouldn't notice multiple locks, only if multiple requestors got one lock, so perhaps there's a loophole in the standalone tests.

I think I could prevent the problem by simply making the first decision stick, but still am not quite sure what path it is taking, which I'd like to know to insure I fix it properly.

Some decisions in the code path:

Is the lockerd running on the same system as the machine requesting the lock or other machines owning these locks?

This request didn't have a timeout, but do any of the other requestors of these locks?

This request didn't have a autounlock, but do any of the other requestors of these locks?

#4 Updated by Wilson Snyder almost 10 years ago

Offline Krishna developed a patch to fix the mis-duplication of commands to the server.

Is this now running ok for you? I'd like to push the release.

#5 Updated by Wilson Snyder almost 10 years ago

  • Status changed from AskedReporter to Closed

Released as 1.486.

Also available in: Atom