svn commit: r188727 - in stable/7: sys sys/contrib/pf
sys/dev/ath/ath_hal sys/dev/cxgb sys/kern sys/modules/sem
sys/sys tools/regression/posixsem usr.bin/procstat
John Baldwin
jhb at freebsd.org
Wed Feb 18 07:55:06 PST 2009
On Wednesday 18 February 2009 10:17:49 am Bruce Simpson wrote:
> John Baldwin wrote:
> > ...
> >
> >> I just tested this and Python 2.5 still dumps core in sem_open() when
> >> called from semlock_new() in _multiprocessing.so, this is with the most
> >> recent back-port of multiprocessing to Python 2.5:
> >> http://pypi.python.org/pypi/multiprocessing
> >>
> >
> > Do you have a core dump with symbols? If so, can you get the trace?
> >
>
> Here you are... have runtime ELF symbols but no line numbers.
>
> I had to comment out some stuff in its "setup.py" to persuade the
> _multiprocessing C shim to use sem_open() (remove freebsd7 and/or
> freebsd8 from that file before "python setup.py config" and "python
> setup.py build").
>
> I was running the Doc/includes/mp_benchmarks.py file which ships with
> multiprocessing.
>
> multiprocessing is part of Python 2.6 base now, so likely what is Not OK
> in the backport, would need to be forward-ported when it is happy with
> sem_open() in Python 2.5.
Hmm, by symbols I meant having things built with debug symbols (i.e. "-g").
Also, do you have 'sem.ko' loaded? The only reason I can think of why you
would get a core dump in ksem_open() itself would be if you got a SIGSYS
because the module wasn't loaded.
--
John Baldwin
More information about the svn-src-stable-7
mailing list