resc thomat...@gmail.com added the comment:
This was fixed in stable releases of the Ubuntu
kernels on Mar 16, 2010 (though the fix was
included in Ubuntu 9.10 when it was released
Oct 29, 2009).
--
___
Python tracker rep...@bugs.python.org
resc thomat...@gmail.com added the comment:
Argh, that e-mail didn't work. Anyway, I just wanted to say that the kernel
explanation is consistent with my experience, I had a crash every week up until
recently, when I upgraded, but in the past few days I haven't been able to
reproduce it.
Charles-Francois Natali neolo...@free.fr added the comment:
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
Matthias Klose d...@debian.org added the comment:
That would explain why it's only reported on Ubuntu
the original report is from the rPath distribution.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7332
Charles-Francois Natali neolo...@free.fr added the comment:
the original report is from the rPath distribution.
Never heard of this one, but
http://wiki.rpath.com/wiki/rPath_Linux:rPath_Linux_2 states:
Compile with --fstack-protectorand FORTIFY_SOURCE=2 (override in your recipes
by
Kees Cook k...@ubuntu.com added the comment:
The stack protector will add 8 (aligned, so possibly padded) bytes to each
stack frame of functions with arrays of 8 or greater bytes. So if things are
marginal, this could make the difference between Pythons compiled with/without
STINNER Victor victor.stin...@haypocalc.com added the comment:
Here is a short shell script to reproduce the stack overflow:
- create 100 Python modules: stack1 imports stack2, stack2 imports stack3,
, and stack100 prints hello
- each module calls os.system(cat /proc/%s/maps|grep stack %
Kees Cook k...@ubuntu.com added the comment:
So, digging a little further, I think this is a now-fixed kernel bug with stack
growth. There were known issues prior to Sep 2009 with 64bit stack growth with
ASLR, which is enabled by default. Upstream fix:
Antoine Pitrou pit...@free.fr added the comment:
Thank you Kees, this sounds quite likely. I will still commit the patch to
remove the stack buffer, and then close this issue.
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou pit...@free.fr added the comment:
Patch committed in trunk (r80325) and py3k (r80326). I won't backport it to
2.6/3.1 since it's not likely to fix anything in practice -- it's just a nice
simplification. Thanks everyone for comments and patches.
--
resolution: - works
STINNER Victor victor.stin...@haypocalc.com added the comment:
I tried to limit memory allocated on the stack while importing modules. Number
of bytes allocated on the stack:
- without my patch: 13792 bytes per import
- with my patch: 1632 bytes per import
(using import_stackoverflow.sh,
Matthias Klose d...@debian.org added the comment:
Does Ubuntu use a small stack size?
it's 8192 on all architectures.
--
nosy: +doko
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7332
___
Matthias Klose d...@debian.org added the comment:
I'm told it's 10240 on Fedora 12, x86 and x86_64
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7332
___
STINNER Victor victor.stin...@haypocalc.com added the comment:
Allocate more than 16 bytes on the stack is never a good idea. Eg. Linux does
never resize the size automatically, and the only way to catch allocatation
failed error is to handle the SIGSEGV signal...
Remove buf allocated on the
Antoine Pitrou pit...@free.fr added the comment:
A 16KB stack buffer is tiny compared to a 8MB stack. I'm not sure removing that
buffer would really fix the problems.
Perhaps other threads get a smaller stack?
--
___
Python tracker
Antoine Pitrou pit...@free.fr added the comment:
What's the value of MAXPATHLEN and PATH_MAX on those systems?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7332
___
Charles-Francois Natali neolo...@free.fr added the comment:
The problem is highlighted with recursive imports:
a module which imports another module, which imports another module, etc.
PyMarshal_ReadLastObjectFromFile is not the only function to use
stack-allocated buffers, there are also
Antoine Pitrou pit...@free.fr added the comment:
The problem is highlighted with recursive imports:
a module which imports another module, which imports another module,
etc. PyMarshal_ReadLastObjectFromFile is not the only function to use
stack-allocated buffers, there are also
resc thomat...@gmail.com added the comment:
Hi,
I'm working on reproducing this again, but it's always been a very
sporadic bug, and I haven't gotten a bingo yet.
- return the result of ulimit -s on their box
8192
- return the result of ltrace -e pthread_attr_setstacksize command
used to start
Matthias Klose d...@debian.org added the comment:
PATH_MAX/MAXPATHLEN is 4096
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7332
___
___
Changes by Charles-Francois Natali neolo...@free.fr:
--
nosy: +ezio.melotti
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7332
___
___
Antoine Pitrou pit...@free.fr added the comment:
I agree that we can consider dropping the static buffer and always using
PyMem_MALLOC().
It looks a bit strange for this bug to happen, though. Does Ubuntu use a small
stack size?
--
nosy: +pitrou, tim_one
Antoine Pitrou pit...@free.fr added the comment:
Oh, and the record of the original patch conversation (when this optimization
was added) can be found here:
http://mail.python.org/pipermail/patches/2001-January/003500.html
--
priority: normal - high
versions: +Python 2.7, Python 3.1,
Antoine Pitrou pit...@free.fr added the comment:
A small benchmark shows no difference in startup time when disabling the stack
buffer. (this is on Linux: of course, the problem might be that the glibc is
heavily optimized)
The benchmark was a simple:
$ time ./python -E -c import logging,
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +dmalcolm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7332
___
___
Python-bugs-list
Charles-Francois Natali neolo...@free.fr added the comment:
It looks a bit strange for this bug to happen, though. Does Ubuntu use a
small stack size?
There are other possible reasons:
- the programs that crash (or the libraries they're using) use the stack a lot
- somehow,
Charles-Francois Natali neolo...@free.fr added the comment:
Ok, I've done too some trivial benchmarking on my Linux box, and I get this:
right now:
$ time ./python /tmp/test_import.py
real0m1.258s
user0m1.111s
sys 0m0.101s
with mmap:
$ time ./python /tmp/test_import.py
real
Changes by Charles-Francois Natali neolo...@free.fr:
Removed file: http://bugs.python.org/file16960/marshal_stack.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7332
___
Charles-Francois Natali neolo...@free.fr added the comment:
It's definitely a stack overflow.
Most of the backtraces show an important number of frames.
The last frame is this:
#0 PyMarshal_ReadLastObjectFromFile (fp=0x13e8200)
at ../Python/marshal.c:1026
filesize = value optimized
Thomas Smith thomat...@gmail.com added the comment:
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. There are several
New submission from liang xfanli...@hotmail.com:
In our testbed,we have seem serveral sgement fault in our python scrit.
The enviroment is:
linux=2.6.29.6-0.6.smp.gcc4.1.x86_64
python=2.4.4-41.4-1
GCC = GCC 4.1.2 20070626 (rPath Inc.)] on linux2
Below are the detail call stack:
(gdb) bt
#0
31 matches
Mail list logo
