Date: Wed, 11 Jan 2012 15:33:30 +0100 From: Ivan Voras <ivoras@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org, davidxu@freebsd.org Subject: Re: sem(4) lockup in python? Message-ID: <CAF-QHFWFvYTPeM68Mk%2BOYVX--MNhKOJ2o1GF9ZOsBmtiC5fYFQ@mail.gmail.com> In-Reply-To: <201201110806.30620.jhb@freebsd.org> References: <jejrbe$or8$1@dough.gmane.org> <201201110806.30620.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11 January 2012 14:06, John Baldwin <jhb@freebsd.org> wrote: > On Wednesday, January 11, 2012 6:21:18 am Ivan Voras wrote: >> The lang/python27 port can optionally be built with the support for >> POSIX semaphores - i.e. sem(4). This option is labeled as experimental >> so it may be that the code is simply incorrect. I've tried it and get >> frequent hangs with the python process in the "usem" state. The kernel >> stack is as follows and looks reasonable: >> >> # procstat -kk 19008 >> =C2=A0 =C2=A0PID =C2=A0 =C2=A0TID COMM =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 TDNAME =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 KSTACK >> >> 19008 101605 python =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mi_switch+0x174 >> sleepq_catch_signals+0x2f4 sleepq_wait_sig+0x16 _sleep+0x269 >> do_sem_wait+0xa19 __umtx_op_sem_wait+0x51 amd64_syscall+0x450 >> Xfast_syscall+0xf7 >> >> The process doesn't react to SIGINT or SIGTERM but fortunately reacts to >> SIGKILL. >> >> This could be an error in Python code but OTOH this code is not >> FreeBSD-specific so it's unlikely. > > This is using the new umtx-based semaphore code that David Xu wrote. =C2= =A0He is > probably the best person to ask (cc'd). > Ok, I've encountered the problem repeatedly while building databases/tdb: it uses Python in the build process (but maybe it needs something else in parallel to provoke the problem).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAF-QHFWFvYTPeM68Mk%2BOYVX--MNhKOJ2o1GF9ZOsBmtiC5fYFQ>