Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #73275 > unrolled thread

Re: tempfile.py", line 83, in <module> once_lock = _allocate_lock() thread.error: can't allocat lock

Started byCameron Simpson <cs@zip.com.au>
First post2014-06-14 15:18 +1000
Last post2014-06-14 15:18 +1000
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: tempfile.py", line 83, in <module> once_lock = _allocate_lock() thread.error: can't allocat lock Cameron Simpson <cs@zip.com.au> - 2014-06-14 15:18 +1000

#73275 — Re: tempfile.py", line 83, in <module> once_lock = _allocate_lock() thread.error: can't allocat lock

FromCameron Simpson <cs@zip.com.au>
Date2014-06-14 15:18 +1000
SubjectRe: tempfile.py", line 83, in <module> once_lock = _allocate_lock() thread.error: can't allocat lock
Message-ID<mailman.11062.1402723125.18130.python-list@python.org>
On 14Jun2014 01:40, SABARWAL, SHAL <ss3141@att.com> wrote:
>Appreciate any help in resolving/understanding following error.
>Very occasionally get following error. The error occurs once every 20 - 30 days. OS HP-UX 11.11
>
>############### ERROR LISTNG #############################
>sem_init: Device busy
[...]
>        once_lock = _allocate_lock()
>        thread.error: can't allocate lock
[...]

This looks like (erroneous) reuse of a previously allocated anonymous 
semaphore. Have a read of HP-UX's sem_init(2) manual page:

   http://condor.depaul.edu/dmumaugh/readings/handouts/CSC343/pthreads_man%20pages/semaphore.txt

This will be the underlying OS interface used to make a Python lock. It takes 
as an argument a pointer to a piece of memory to represent the semaphore.

That page says that the error code EBUSY ("Device busy") is issued if:

     There are threads currently blocked on the semaphore or there are 
     outstanding locks held on the semaphore.

I would take this to represent a bug in the python code that manages the 
semaphores supporting the Lock objects. It looks like the code reuses a 
previous sem_t C object while it is still in use. Since this happens very 
rarely for you I would guess this is a race condition not detected in testing.

I guess my first question would be: what release of Python are you running?

Have you considered getting the latest source code for Python ( version 2 or 3 
according to what your code is using) and building that? It may be that this 
issue has been fixed in a later release of Python than the one currently 
installed on your HP-UX box.

Cheers,
Cameron Simpson <cs@zip.com.au>

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web