One of our application recently started to segfault in
PyObject_Malloc(). The cause of the problem could be tracked down to an
overflowing internal cache.

However I was astonished that Python was segfaulting instead of raising
a memory exception. I did some post mortem debugging with gdb and found
an address out of bounds problem. I think the issue is caused by the
limited heap of a 32bit Python process.

(gdb) bt
...
#7  <signal handler called>
#8  PyObject_Malloc (nbytes=40) at Objects/obmalloc.c:747
#9  0xb7edfba5 in _PyObject_GC_Malloc (basicsize=28) at
Modules/gcmodule.c:1322
#10 0xb7e79867 in PyType_GenericAlloc (type=0xb7606d40, nitems=0) at
Objects/typeobject.c:454
...

(gdb) up 8
#8  PyObject_Malloc (nbytes=40) at Objects/obmalloc.c:747
747                             if ((pool->freeblock = *(block **)bp) !=
NULL) {
(gdb) print pool
$1 = (poolp) 0x17ecc000
(gdb) print pool->freeblock
$2 = (block *) 0xecc778b7 <Address 0xecc778b7 out of bounds>
(gdb) print bp
$3 = (block *) 0xecc778b7 <Address 0xecc778b7 out of bounds>

Python: 2.5.2 (32bit)
OS: SuSE Linux 2.6.16.60-0.33-bigsmp

It was a long time ago, but:
- I think the interpreter will never be able to catch all memory allocation errors, since because of overcommitting (which Linux does), you can very well get a segmentation fault even if the memory allocation routine (be it malloc or mmap) is successful (i.e. doesn't return NULL): so basically, we don't have any way to avoid that, since we will segfault only when we first touch the allocated page
- since your application was "overflowing internal cache", this might very well be what happened (or it could have been a memory corruption issue :-)

Peers ?

Is this reproducible? Has is occurred with 2.7 or 3.x?
Or should be close this?

Not sure if it's caused by the same thing, but I just got a segfault on the same line in my own program.  Running python 2.7.1.

I will try to dig out some more useful info but it's been a long time since I chased a segfault...

Do you have a coredump ?
It'd be curious to see this faulting address.
I didn't notice the first time, but in the OP case the address is definitely wrong: 0xecc778b7 is above PAGE_OFFSET (0xc0000000 on x86), so unless he's using a kernel with a 4G/4G split (and it's not the case since it seems to be a PAE kernel), it's definitely an invalid/corrupt address...

Please remind me how to obtain an appropriate coredump (as I said, it's been a *long* time...)

Doing "print bp" shows an out-of-bounds address as for the original submitter.

attaching core dump from a freshly-compiled python 2.7.1 at with "-O0 -g" in CFLAGS.

The code that is segfaulting is using pycrypto and sqlite3, so it may be that a bug in one of these is trampling on something.  No idea how to investigate any further.

> The code that is segfaulting is using pycrypto and sqlite3, so it may be that a bug in one of these is trampling on something.  No idea how to investigate any further. 

You could try valgrind:
$ valgrind --tool=memcheck -o /tmp/output.log <prog> arguments

This slows down the execution, but can reveal certain types of memory corruption.

Thanks for the help, I have tracked this down to a bug in PyCrypto.  It was increfing an object once but decrefing it twice.

Sorry for the noise.