[logo] 
 
Home
News
Activity
About/Contact
Major Tools
  Dinotrace
  Verilator
  Verilog-mode
  Verilog-Perl
Other Tools
  BugVise
  CovVise
  Force-Gate-Sim
  Gspice
  IPC::Locker
  Rsvn
  Schedule::Load
  SVN::S4
  Synopsys-modes
  SystemPerl
  Verilog-Pli
  Voneline
  Vregs
General Info
  Papers

Issue #237

Returning multiple locks for a single request

Added by Krishna Subramanian about 2 years ago. Updated about 2 years ago.

Status:Closed Start date:04/07/2010
Priority:Normal Due date:
Assignee:Wilson Snyder % Done:

0%
Category:-
Target version:-

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 - Bug instance 1 (2.4 kB) Krishna Subramanian, 04/07/2010 09:42 pm

History

#1
Updated by Wilson Snyder about 2 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 about 2 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 about 2 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 about 2 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 about 2 years ago

  • Status changed from AskedReporter to Closed

Released as 1.486.

Also available in: Atom