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]

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