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
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, this is with the most 
> >> recent back-port of multiprocessing to Python 2.5:
> >>
> >>     
> >
> > 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 "" to persuade the 
> _multiprocessing C shim to use sem_open() (remove freebsd7 and/or 
> freebsd8 from that file before "python config" and "python 
> build").
> I was running the Doc/includes/ 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