Segmentation fault in PyObjectMalloc on FreeBSD
I have a multithreaded python app running on FreeBSD (both 7.0 and
6.3) that crashes with a segmentation fault coming from
PyObjectMalloc. This first happened using Python 2.5 built from Ports.
I then pulled down r261 from Subversion and built that so I would have
debugging symbols; it still crashed. Below is a back trace from gdb:
#0 PyObject_Malloc (nbytes=2) at Objects/obmalloc.c:758
#1 0x080942aa in PyString_FromStringAndSize (str=0x0, size=50) at
Objects/stringobject.c:83
#2 0x0809b30b in PyString_FromFormatV (format=0x813c6d4 "%.50s
instance has no attribute '%.400s'",
vargs=0xbf6fa048 "üõ.\bÄQ\031\bì¯>\b") at Objects/stringobject.c:
238
#3 0x080dcd48 in PyErr_Format (exception=0x8158660, format=0x813c6d4
"%.50s instance has no attribute '%.400s'")
at Python/errors.c:538
#4 0x08064549 in instance_getattr1 (inst=0x833ed4c, name=0x81951b0)
at Objects/classobject.c:717
#5 0x08067c9f in instance_nonzero (self=0x833ed4c) at Objects/
classobject.c:754
#6 0x0808a592 in PyObject_IsTrue (v=0x8473000) at Objects/object.c:
1532
#7 0x080cb6d3 in PyEval_EvalFrameEx (f=0x857860c, throwflag=0) at
Python/ceval.c:2173
#8 0x080cef5d in PyEval_EvalFrameEx (f=0x8574e0c, throwflag=0) at
Python/ceval.c:3765
#9 0x080cef5d in PyEval_EvalFrameEx (f=0x856980c, throwflag=0) at
Python/ceval.c:3765
#10 0x080cfbe8 in PyEval_EvalCodeEx (co=0x82f7218, globals=0x49,
locals=0x815dd40, args=0x819402c, argcount=4, kws=0x83a99a0,
kwcount=0, defs=0x833e758, defcount=2, closure=0x0) at Python/
ceval.c:2942
#11 0x08124260 in function_call (func=0x83408b4, arg=0x846ee64,
kw=0x845546c) at Objects/funcobject.c:524
#12 0x08060402 in PyObject_Call (func=0x83408b4, arg=0x846ee64,
kw=0x845546c) at Objects/abstract.c:2487
#13 0x080cbdbc in PyEval_EvalFrameEx (f=0x856dc0c, throwflag=0) at
Python/ceval.c:3978
#14 0x080cfbe8 in PyEval_EvalCodeEx (co=0x82f6cc8, globals=0x49,
locals=0x815dd40, args=0x819402c, argcount=2, kws=0x8572154,
kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:
2942
#15 0x080cdbda in PyEval_EvalFrameEx (f=0x857200c, throwflag=0) at
Python/ceval.c:3774
#16 0x080cef5d in PyEval_EvalFrameEx (f=0x850860c, throwflag=0) at
Python/ceval.c:3765
#17 0x080cef5d in PyEval_EvalFrameEx (f=0x850940c, throwflag=0) at
Python/ceval.c:3765
#18 0x080cef5d in PyEval_EvalFrameEx (f=0x857680c, throwflag=0) at
Python/ceval.c:3765
#19 0x080cfbe8 in PyEval_EvalCodeEx (co=0x83c5f50, globals=0x49,
locals=0x815dd40, args=0x819402c, argcount=2, kws=0x8506364,
kwcount=0, defs=0x83d1c78, defcount=1, closure=0x0) at Python/
ceval.c:2942
#20 0x080cdbda in PyEval_EvalFrameEx (f=0x850620c, throwflag=0) at
Python/ceval.c:3774
#21 0x080cef5d in PyEval_EvalFrameEx (f=0x850980c, throwflag=0) at
Python/ceval.c:3765
#22 0x080cef5d in PyEval_EvalFrameEx (f=0x84efa0c, throwflag=0) at
Python/ceval.c:3765
#23 0x080cef5d in PyEval_EvalFrameEx (f=0x84ef80c, throwflag=0) at
Python/ceval.c:3765
#24 0x080cef5d in PyEval_EvalFrameEx (f=0x84ef60c, throwflag=0) at
Python/ceval.c:3765
#25 0x080cef5d in PyEval_EvalFrameEx (f=0x84ef40c, throwflag=0) at
Python/ceval.c:3765
#26 0x080cef5d in PyEval_EvalFrameEx (f=0x84ef20c, throwflag=0) at
Python/ceval.c:3765
#27 0x080cfbe8 in PyEval_EvalCodeEx (co=0x82cdf98, globals=0x49,
locals=0x815dd40, args=0x819402c, argcount=1, kws=0x0, kwcount=0,
defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2942
#28 0x08124260 in function_call (func=0x82e8b8c, arg=0x8471dec,
kw=0x0) at Objects/funcobject.c:524
#29 0x08060402 in PyObject_Call (func=0x82e8b8c, arg=0x8471dec,
kw=0x0) at Objects/abstract.c:2487
#30 0x08069bed in instancemethod_call (func=0x49, arg=0x8471dec,
kw=0x0) at Objects/classobject.c:2579
#31 0x08060402 in PyObject_Call (func=0x83e8a7c, arg=0x819402c,
kw=0x0) at Objects/abstract.c:2487
#32 0x080c87da in PyEval_CallObjectWithKeywords (func=0x83e8a7c,
arg=0x819402c, kw=0x0) at Python/ceval.c:3548
#33 0x080fccdd in t_bootstrap (boot_raw=0x83a9910) at ./Modules/
threadmodule.c:425
#34 0x281b05cf in pthread_create () from /usr/lib/libthr.so.2
#35 0x in ?? ()
This part is particularly interesting:
(gdb) frame 1
#1 0x080942aa in PyString_FromStringAndSize (str=0x0, size=50) at
Objects/stringobject.c:83
83 op = (PyStringObject *)PyObject_MALLOC(sizeof
(PyStringObject) + size);
(gdb) print size
$7 = 50
(gdb) print sizeof(PyStringObject)
$8 = 24
(gdb) frame 0
#0 PyObject_Malloc (nbytes=2) at Objects/obmalloc.c:758
758 if ((pool->freeblock = *(block **)bp) !
= NULL) {
(gdb) print nbytes
$9 = 2
So 50 + 24 == 2? Or am I missing something? Can anyone suggest how to
figure out what's really going on here?
--
http://mail.python.org/mailman/listinfo/python-list
Python 2.6, multiprocessing module and BSD
It seems that the multiprocessing module in 2.6 is broken for *BSD; I've seen issue 3770 regarding this. I'm curious if there are more details on this issue since the posts in 3770 were a bit unclear. For example, one post claimed that the problem was that sem_open isn't implemented in *BSD, but it is available on FreeBSD 7 (I checked). I'd be willing to help get this working if someone could point me in the right direction. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.6, multiprocessing module and BSD
On Oct 21, 8:08 pm, Philip Semanchuk <[EMAIL PROTECTED]> wrote: > On Oct 21, 2008, at 6:45 PM, [EMAIL PROTECTED] wrote: > > > It seems that the multiprocessing module in 2.6 is broken for *BSD; > > I've seen issue 3770 regarding this. I'm curious if there are more > > details on this issue since the posts in 3770 were a bit unclear. For > > example, one post claimed that the problem was that sem_open isn't > > implemented in *BSD, but it is available on FreeBSD 7 (I checked). I'd > > be willing to help get this working if someone could point me in the > > right direction. > > Hi Al, > I don't know anything about the multiprocessing module, but I have > some recent experience with the semaphores on FreeBSD 6 & 7 as a > result of implementing my posix_ipc module. > > Since you mentioned sem_open, I assume you're talking about POSIX > semaphores, rather than System V semaphores, yes? On FreeBSD 6 & 7 > sem_open exists and works, but support for said semaphores are listed > as "very experimental". I experienced a problem that looked like a bug > to me, and a rather big one at that. There's more detail here (scroll > down to the part about FreeBSD 6/7) including a link to the bug report > I filed against the FreeBSD kernel: > > http://semanchuk.com/philip/posix_ipc/#platforms > > HTH > Philip Thanks for the background on FreeBSD semaphores. I read through the link; it should help. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.6, multiprocessing module and BSD
On Oct 22, 8:11 am, "Jesse Noller" <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 21, 2008 at 6:45 PM, <[EMAIL PROTECTED]> wrote:
> > It seems that the multiprocessing module in 2.6 is broken for *BSD;
> > I've seen issue 3770 regarding this. I'm curious if there are more
> > details on this issue since the posts in 3770 were a bit unclear. For
> > example, one post claimed that the problem was that sem_open isn't
> > implemented in *BSD, but it is available on FreeBSD 7 (I checked). I'd
> > be willing to help get this working if someone could point me in the
> > right direction.
> > --
> >http://mail.python.org/mailman/listinfo/python-list
>
> The BSD issue was raised late in the cycle for 2.6. The problem is
> that FBSD's support is "very experimental" as Phillip points out - and
> OpenBSD doesn't even have them.
>
> Due to the lateness of the issue and a finite amount of time I have to
> work on things, I chose to disable support for this on the various
> *BSDs until I can cook up a stable patch or have one provided by
> someone more familiar with the inner workings of Free-BSD. OpenBSD
> support is a non-starter.
>
> Ideally, I would like to get this fixed and put on the 2.6 maint
> branch ASAP, but I haven't had a chance to circle back to it.
>
> Also note Nick's comment in that bug: "Unfortunately, our OpenBSD and
> FreeBSD buildbots are so unreliable that they don't get much attention
> when they go red"
>
> Stable reliable buildbots and a few more volunteers more familiar with
> BSDs might be a great and welcome addition to python-dev.
>
> As for getting this working - I would love a patch. You are going to
> want to start with python-trunk and look in setup.py. You are going to
> want to adjust the flags the package uses:
>
> elif platform in ('freebsd5', 'freebsd6', 'freebsd7', 'freebsd8'):
> # FreeBSD's P1003.1b semaphore support is very experimental
> # and has many known problems. (as of June 2008)
> macros = dict( # FreeBSD
> HAVE_SEM_OPEN=0,
> HAVE_SEM_TIMEDWAIT=0,
> HAVE_FD_TRANSFER=1,
> )
> libraries = []
>
> You will also need to look at: Lib/multiprocessing/synchronize.py to
> disable the import error - Modules/_multiprocessing/multiprocessing.h
> will need to be updated for the proper ifdefs for the bsd(s) as well.
> Finally, the core of the semaphore usage is in
> Modules/_multiprocessing/semaphore.c
>
> I apologize we/I could not get this in for 2.6
>
> -jesse
This is exactly the sort of response I was hoping for. Thanks for the
additional background on the problem. I'll take a look at the code and
see if I can figure out a patch. I'll also read up on the buildbot
issue ( I think I saw a link about that)...I might have a stable co-
located FreeBSD box that could be used.
-Alan
--
http://mail.python.org/mailman/listinfo/python-list
