"sem_post: Invalid argument"
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 22.214.171.124-p4-smp-bigmem-JWH #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
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