Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!rt.uk.eu.org!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.000 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'argument': 0.05; 'that?': 0.05; 'occasionally': 0.09; 'subject: <': 0.09; 'subject:module': 0.09; 'cc:addr:python-list': 0.11; 'python': 0.11; 'bug': 0.12; 'be:': 0.16; 'blocked': 0.16; 'detected': 0.16; 'from:addr:cs': 0.16; 'from:addr:zip.com.au': 0.16; 'from:name:cameron simpson': 0.16; 'message-id:@cskk.homeip.net': 0.16; 'objects.': 0.16; 'rarely': 0.16; 'received:211.29': 0.16; 'received:211.29.132': 0.16; 'received:cskk.homeip.net': 0.16; 'received:homeip.net': 0.16; 'received:optusnet.com.au': 0.16; 'received:syd.optusnet.com.au': 0.16; 'simpson': 0.16; 'subject:lock': 0.16; 'subject:skip:_ 10': 0.16; 'underlying': 0.16; 'skip:# 20': 0.16; 'wrote:': 0.18; 'later': 0.20; 'memory': 0.22; 'manual': 0.22; 'previously': 0.22; 'cc:addr:python.org': 0.22; 'header:User-Agent:1': 0.23; 'error': 0.23; 'pointer': 0.24; 'cheers,': 0.24; 'looks': 0.24; 'question': 0.24; 'cc:2**0': 0.24; 'source': 0.25; 'url:edu': 0.26; 'header:In-Reply-To:1': 0.27; 'installed': 0.27; 'to:2**1': 0.27; 'fixed': 0.29; 'code': 0.31; 'getting': 0.31; 'anonymous': 0.31; 'occurs': 0.31; 'piece': 0.31; 'testing.': 0.31; 'interface': 0.32; 'says': 0.33; 'guess': 0.33; 'device': 0.34; 'skip:_ 10': 0.34; "can't": 0.35; 'building': 0.35; 'there': 0.35; 'version': 0.36; 'received:com.au': 0.36; 'skip:> 10': 0.36; 'charset:us-ascii': 0.36; 'error.': 0.37; 'represent': 0.38; 'outstanding': 0.38; 'received:211': 0.38; 'issue': 0.38; 'previous': 0.38; 'subject:can': 0.39; 'supporting': 0.39; 'use.': 0.39; 'according': 0.40; 'release': 0.40; 'read': 0.60; 'url:%20': 0.61; 'first': 0.61; 'content- disposition:inline': 0.62; 'latest': 0.67; 'issued': 0.93; 'race': 0.95 Date: Sat, 14 Jun 2014 15:18:39 +1000 From: Cameron Simpson To: "SABARWAL, SHAL" Subject: Re: tempfile.py", line 83, in once_lock = _allocate_lock() thread.error: can't allocat lock MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) References: X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=QIpRGG7L c=1 sm=1 tr=0 a=YuQlxtEQCowy2cfE5kc7TA==:117 a=YuQlxtEQCowy2cfE5kc7TA==:17 a=ZtCCktOnAAAA:8 a=PO7r1zJSAAAA:8 a=LcaDllckn3IA:10 a=gR1MAmOQAJQA:10 a=kj9zAlcOel0A:10 a=vrnE16BAAAAA:8 a=zQP7CpKOAAAA:8 a=KuO-m8wKAAAA:8 a=CVyuN-QLA4DK464wuCoA:9 a=CjuIK1q_8ugA:10 a=Hz7IrDYlS0cA:10 Cc: "python-list@python.org" X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 38 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1402723125 news.xs4all.nl 2930 [2001:888:2000:d::a6]:38027 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:73275 On 14Jun2014 01:40, SABARWAL, SHAL 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