> And that report shows only a single thread, so I have to assume that the
8MB figure applies there.

> Nevertheless, we can remove the stack buffer since it's probably
useless. It just seems unlikely to me to be the root cause of the stack
overflow.

If we really have an 8MB stack, yes, it's unlikely. But max stack size is inherited by child processes, and see for example streamtuner (one of the reports):
http://bugs.gentoo.org/274056

--- src/streamtuner/st-thread.c
+++ src/streamtuner/st-thread.c
@@ -108,1 +108,1 @@
-			     0x18000, /* 96k, big enough for libcurl */
+			     0x40000, /* change from 96k to 256k */

So if we start with this stack size, we can run out of stack space really easily: I counted around 20 bufs allocation in some backtraces, and with MAXPATHLEN to 4K, it's 20 * 4 + 16 = 96K used.

There might be another reason. I think that Ubuntu's using gcc SSP feature by default, to prevent buffer overflows and friends, so maybe there's something going on with this. That would explain why it's only reported on Ubuntu (well, they also have more users, but let's assume there's really something specific on Ubuntu).

> I'm also getting segfaults in PyMarshal_ReadLastObjectFromFile in Python 2.6.2 (on Ubuntu Jaunty).  It's very sporadic, I've been reproducing it by running a minimal script 100,000 times, and getting a few core dumps.

I've had a look at your backtraces, and when it segfaults, the stack size is _really_ far from 8M. So there's realy somthing fishy going on here. Are you getting an error message printed beside the usual segmentation fault ? Could you try to reproduce with your test script with a python compiled with -fno-stack-protector and -U_FORTIFY_SOURCE ?