"sem_post: Invalid argument"

robert no-spam at not-existing.invalid
Sat Oct 27 11:50:06 CEST 2007

Jonathan Gardner wrote:
> On Oct 25, 2:19 pm, robert <no-s... at not-existing.invalid> wrote:
>> Jonathan Gardner wrote:
>>> On Oct 25, 12:56 pm, robert <no-s... at not-existing.invalid> wrote:
>>>> On a server the binary (red hat) installed python2.4 and also a
>>>> fresh compiled python2.5 spits "sem_post: Invalid argument".
>>>> What is this and how can this solved?
>>>> ...
>>>> Python 2.4.3 (#1, Jun  6 2006, 21:10:41)
>>>> [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-54)] on linux2
>>>> ...
>>>> server [~]# uname -a
>>>> Linux server #1 SMP Mon Mar 19 03:26:57
>>>> JST 2007 i686 i686 i386 GNU/Linux
>>> Are you sure you have compatible binaries? Or did you install a random
>>> RPM without checking for dependencies?
>> Should be compatible - but I am not sure if the kernel was
>> recompiled on this machine. And at least the fresh ./configure'ed
>> and compiled py2.5, which yields the same problem, should be
>> maximum compatible. Maybe because this machine is a "smp-bigmem" ..
> At this point, I would start digging into the error messages
> themselves. Maybe a shout out to the developers of whatever code is
> generating that error message. When you understand under what
> conditions that error message is thrown, perhaps it will yield some
> insight into what python is doing differently than everything else.

In the Python2.4 sources just this piece causes the sem_post error 

PyThread_release_lock(PyThread_type_lock lock)
	sem_t *thelock = (sem_t *)lock;
	int status, error = 0;

	dprintf(("PyThread_release_lock(%p) called\n", lock));

	status = sem_post(thelock);


     The sem_post() function will fail if:

         The sem does not refer to a valid semaphore.

with EINVAL - to me the only remaining reason is somehow a wrong 
sem_t memory layout - in the C compiler header file on this rented 
server - though the lock was established ok!?? ...

More information about the Python-list mailing list