[issue3234] subprocess.py strips last character when raising an AttributeError
New submission from Martin Mokrejs <[EMAIL PROTECTED]>: I try to get working pipe emulation using Popen. I try to pass StringIO object to p1.stdin of the first process and I got the following: File "/usr/lib/python2.5/subprocess.py", line 587, in __init__ errread, errwrite) = self._get_handles(stdin, stdout, stderr) File "/usr/lib/python2.5/subprocess.py", line 932, in _get_handles p2cread = stdin.fileno() AttributeError: 'cStringIO.StringI' object has no attribute 'fileno' Aside from the fact I would hope that cStringIO could provide self.fileno() I believe the error message should have been: AttributeError: 'cStringIO.StringIO' object has no attribute 'fileno' -- components: Library (Lib) messages: 68942 nosy: mmokrejs severity: normal status: open title: subprocess.py strips last character when raising an AttributeError type: crash versions: Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3234> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3235] Improve subprocess module usage
New submission from Martin Mokrejs <[EMAIL PROTECTED]>: Although I do appreciate that you try to improve python it is not clear to me from http://docs.python.org/lib/module-subprocess.html: 1. Why the old functions have been deprecated 2. I can pipe together two processes. But how can I use pipe to feed the first process of the two? The example at http://docs.python.org/lib/node535.html is not sufficient. Show how to bind together cat(1) and tr(1). Cat should read from STDIN and pass the same to STDOUT, being read by tr(1). 3. Nowhere is explained what this magic really does: output = p2.communicate()[0] I figured out the result is e.g. a string of '\n' separated lines. What is not clear whether at this very moment the processes get started and whether one can still write on input to them. It seems not, the p1.stdin has to be already populated with data. Thanks. -- assignee: georg.brandl components: Documentation messages: 68943 nosy: georg.brandl, mmokrejs severity: normal status: open title: Improve subprocess module usage type: resource usage versions: Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3235> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3235] Improve subprocess module usage
Martin Mokrejs <[EMAIL PROTECTED]> added the comment: Please link to http://www.python.org/dev/peps/pep-0324/ from the docs webpage at least. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3235> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3235] Improve subprocess module usage
Martin Mokrejs <[EMAIL PROTECTED]> added the comment: Georg, but would you please improve the docs explaining what communicate really does? The syntax is nice but I don't see how can I use poll() described in the same above to use that. Providing Examples section would be the best. Of course I don't mind if the examples come from Doug Hellman or not, as mentioned in msg68956. ;-) Or how about placing a link to that page (http://blog.doughellmann.com/2007/07/pymotw-subprocess.html)? Please reopen unless better docs are available. I don't care about 2.6 either, sorry. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3235> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when available
New submission from Martin Mokrejs <[EMAIL PROTECTED]>: Hi, although the issues libraries to be created with -fpic are known I still do believe ./config could do something here: building 'crypt' extension gcc -shared -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/cryptmodule.o -L/usr/local/lib -lcrypt -o build/lib.solaris-2.6-sun4u-2.5/crypt.so Text relocation remains referenced against symbol offset in file _des_setkey 0x4 /usr/lib/libcrypt.a(crypt.o) _des_encrypt0x10/usr/lib/libcrypt.a(crypt.o) _des_crypt 0x1c/usr/lib/libcrypt.a(crypt.o) 0x4 /usr/lib/libcrypt.a(des_crypt.o) 0x8 /usr/lib/libcrypt.a(des_crypt.o) ... ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status # gcc -shared -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/cryptmodule.o -L/usr/local/lib -lcrypto -o build/lib.solaris-2.6-sun4u-2.5/crypt.so # -- components: Build messages: 69144 nosy: mmokrejs severity: normal status: open title: Use -lcrypto instead of -lcrypt on Solaris 2.6 when available versions: Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3264> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3265] Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error: `MAP_ANONYMOUS' undeclared
New submission from Martin Mokrejs <[EMAIL PROTECTED]>: Hi, when building on Solaris 2.6 with gcc I get the following error: building '_ctypes' extension gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include -Ibuild/temp.solaris-2.6-sun4u-2.5/libffi/include -Ibuild/temp.solaris-2.6-sun4u-2.5/libffi -I/usr/scratch/Python-2.5.2/Modules/_ctypes/libffi/src -I. -IInclude -I./Include -I/usr/local/include -I/usr/scratch/Python-2.5.2/Include -I/usr/scratch/Python-2.5.2 -c /usr/scratch/Python-2.5.2/Modules/_ctypes/_ctypes.c -o build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/_ctypes.o gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include -Ibuild/temp.solaris-2.6-sun4u-2.5/libffi/include -Ibuild/temp.solaris-2.6-sun4u-2.5/libffi -I/usr/scratch/Python-2.5.2/Modules/_ctypes/libffi/src -I. -IInclude -I./Include -I/usr/local/include -I/usr/scratch/Python-2.5.2/Include -I/usr/scratch/Python-2.5.2 -c /usr/scratch/Python-2.5.2/Modules/_ctypes/callbacks.c -o build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/callbacks.o gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include -Ibuild/temp.solaris-2.6-sun4u-2.5/libffi/include -Ibuild/temp.solaris-2.6-sun4u-2.5/libffi -I/usr/scratch/Python-2.5.2/Modules/_ctypes/libffi/src -I. -IInclude -I./Include -I/usr/local/include -I/usr/scratch/Python-2.5.2/Include -I/usr/scratch/Python-2.5.2 -c /usr/scratch/Python-2.5.2/Modules/_ctypes/callproc.c -o build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/callproc.o /usr/scratch/Python-2.5.2/Modules/_ctypes/callproc.c: In function `_CallProc': /usr/scratch/Python-2.5.2/Modules/_ctypes/callproc.c:921: warning: implicit declaration of function `alloca' gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include -Ibuild/temp.solaris-2.6-sun4u-2.5/libffi/include -Ibuild/temp.solaris-2.6-sun4u-2.5/libffi -I/usr/scratch/Python-2.5.2/Modules/_ctypes/libffi/src -I. -IInclude -I./Include -I/usr/local/include -I/usr/scratch/Python-2.5.2/Include -I/usr/scratch/Python-2.5.2 -c /usr/scratch/Python-2.5.2/Modules/_ctypes/stgdict.c -o build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/stgdict.o gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include -Ibuild/temp.solaris-2.6-sun4u-2.5/libffi/include -Ibuild/temp.solaris-2.6-sun4u-2.5/libffi -I/usr/scratch/Python-2.5.2/Modules/_ctypes/libffi/src -I. -IInclude -I./Include -I/usr/local/include -I/usr/scratch/Python-2.5.2/Include -I/usr/scratch/Python-2.5.2 -c /usr/scratch/Python-2.5.2/Modules/_ctypes/cfield.c -o build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/cfield.o gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include -Ibuild/temp.solaris-2.6-sun4u-2.5/libffi/include -Ibuild/temp.solaris-2.6-sun4u-2.5/libffi -I/usr/scratch/Python-2.5.2/Modules/_ctypes/libffi/src -I. -IInclude -I./Include -I/usr/local/include -I/usr/scratch/Python-2.5.2/Include -I/usr/scratch/Python-2.5.2 -c /usr/scratch/Python-2.5.2/Modules/_ctypes/malloc_closure.c -o build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/malloc_closure.o /usr/scratch/Python-2.5.2/Modules/_ctypes/malloc_closure.c: In function `more_core': /usr/scratch/Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error: `MAP_ANONYMOUS' undeclared (first use in this function) /usr/scratch/Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error: (Each undeclared identifier is reported only once /usr/scratch/Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error: for each function it appears in.) building '_ctypes_test' extension gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include -I. -IInclude -I./Include -I/usr/local/include -I/usr/scratch/Python-2.5.2/Include -I/usr/scratch/Python-2.5.2 -c /usr/scratch/Python-2.5.2/Modules/_ctypes/_ctypes_test.c -o build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/_ctypes_test.o gcc -shared -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/_ctypes_test.o -L/usr/local/lib -o build/lib.solaris-2.6-sun4u-2.5/_ctypes_test.so Let me add that I see -fPIC in the top-level Makefile but do not know why -static is not in the same variable as well. Anyway, it is not a shared library problem I think as I already recompiled my bzip2, openssl and ncurses libs with "-shared -fpic". ;-) -- messages: 69152 no
[issue3266] Python-2.5.2/Modules/mmapmodule.c:915: error: `O_RDWR' undeclared
New submission from Martin Mokrejs <[EMAIL PROTECTED]>: Some typo in the sources showing up on Solaris 2.6 only? building 'mmap' extension gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include -I. -IInclude -I./Include -I/usr/local/include -I/usr/scratch/Python-2.5.2/Include -I/usr/scratch/Python-2.5.2 -c /usr/scratch/Python-2.5.2/Modules/mmapmodule.c -o build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/mmapmodule.o /usr/scratch/Python-2.5.2/Modules/mmapmodule.c: In function `new_mmap_object': /usr/scratch/Python-2.5.2/Modules/mmapmodule.c:915: warning: implicit declaration of function `open' /usr/scratch/Python-2.5.2/Modules/mmapmodule.c:915: error: `O_RDWR' undeclared (first use in this function) /usr/scratch/Python-2.5.2/Modules/mmapmodule.c:915: error: (Each undeclared identifier is reported only once /usr/scratch/Python-2.5.2/Modules/mmapmodule.c:915: error: for each function it appears in.) -- components: Build messages: 69153 nosy: mmokrejs severity: normal status: open title: Python-2.5.2/Modules/mmapmodule.c:915: error: `O_RDWR' undeclared versions: Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3266> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when available
Martin Mokrejs <[EMAIL PROTECTED]> added the comment: # ar tv /usr/lib/libcrypt.a rw-rw-r-- 0/1 1296 Jul 16 05:57 1997 crypt.o rw-rw-r-- 0/1 4996 Jul 16 05:57 1997 cryptio.o rw-rw-r-- 0/1 1508 Jul 16 05:57 1997 des_encrypt.o rw-rw-r-- 0/1 5356 Jul 16 05:58 1997 des_crypt.o # ls -la /usr/lib/libcrypt.so ls: cannot access /usr/lib/libcrypt.so: No such file or directory # ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3264> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3265] Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error: `MAP_ANONYMOUS' undeclared
Martin Mokrejs <[EMAIL PROTECTED]> added the comment: A Goggle search gives between many others: http://gcc.gnu.org/ml/gcc/2000-09/msg00054.html http://www.ravenbrook.com/project/mps/master/design/vmso/ http://developers.sun.com/solaris/articles/read_mmap.html Added file: http://bugs.python.org/file10799/mmap.2 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3265> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3265] Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error: `MAP_ANONYMOUS' undeclared
Martin Mokrejs <[EMAIL PROTECTED]> added the comment: http://unix.derkeiler.com/Newsgroups/comp.unix.solaris/2004-07/0256.html http://source.winehq.org/source/libs/wine/mmap.c I will stop posting URLs. ;-) ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3265> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when available
Martin Mokrejs <[EMAIL PROTECTED]> added the comment: # ar x /usr/lib/libcrypt.a;nm -g des_crypt.o U ___errno 033c T _des_crypt 0274 T _des_encrypt U _des_encrypt1 01b0 T _des_setkey U _mutex_lock U _mutex_unlock U _thr_getspecific U _thr_keycreate U _thr_setspecific 033c W des_crypt 0274 W des_encrypt 01b0 W des_setkey U free U malloc # The installation is actually very fresh, as I re-installed the machine some year ago but it was turned off since few days. With whatever last aggregate patches were available on dying Solaris web pages. # gcc -v Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.6/3.4.2/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls --disable-libgcj --enable-languages=c,c++ Thread model: posix gcc version 3.4.2 # ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3264> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3266] Python-2.5.2/Modules/mmapmodule.c:915: error: `O_RDWR' undeclared
Martin Mokrejs <[EMAIL PROTECTED]> added the comment: So adding these two lines helped: # diff /usr/scratch/Python-2.5.2/Modules/mmapmodule.c.ori /usr/scratch/Python-2.5.2/Modules/mmapmodule.c 36a37 > #include 38a40 > #include # ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3266> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3265] Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error: `MAP_ANONYMOUS' undeclared
Martin Mokrejs <[EMAIL PROTECTED]> added the comment: Thanks, but I can only help with testing. :( ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3265> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when available
Martin Mokrejs <[EMAIL PROTECTED]> added the comment: Could it be the name clashing problem between -lcrypt and -lcrypto? bash-3.00# ar x /usr/lib/libcrypt.a;nm -g des_crypt.o U ___errno 033c T _des_crypt 0274 T _des_encrypt U _des_encrypt1 01b0 T _des_setkey U _mutex_lock U _mutex_unlock U _thr_getspecific U _thr_keycreate U _thr_setspecific 033c W des_crypt 0274 W des_encrypt 01b0 W des_setkey U free U malloc bash-3.00# ar x /usr/local/lib/libcrypto.a;nm -g des_crypt.o U ___errno 033c T _des_crypt 0274 T _des_encrypt U _des_encrypt1 01b0 T _des_setkey U _mutex_lock U _mutex_unlock U _thr_getspecific U _thr_keycreate U _thr_setspecific 033c W des_crypt 0274 W des_encrypt 01b0 W des_setkey U free U malloc bash-3.00# There used to be name clashes between -lcrypt from KTH-KRB/HEIMDAL with those from openssl -lcrypto in the past. I think that was "fixed" around/in openssl-2.7 and heimdal-1.0. The clashes caused openssh dying when compiled with kerberos4 support because the functions of same names expected in some way different data. I am sure you would Goggle it out. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3264> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when available
Martin Mokrejs <[EMAIL PROTECTED]> added the comment: You say "did always work"? http://mail.python.org/pipermail/python-list/2002-December/177479.html Maybe the reason why in ruby they forced to -shared flag because it was possible to link only with the shared library? I do not know from which package to get the shared version. :( http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/33517 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3264> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when available
Martin Mokrejs <[EMAIL PROTECTED]> added the comment: Confirming the enabling line 216 like below helped. Thanks. Maybe change "Resolution"? 204 # Socket module helper for SSL support; you must comment out the other 205 # socket line above, and possibly edit the SSL variable: 206 #SSL=/usr/local/ssl 207 #_ssl _ssl.c \ 208 # -DUSE_SSL -I$(SSL)/include -I$(SSL)/include/openssl \ 209 # -L$(SSL)/lib -lssl -lcrypto 210 211 # The crypt module is now disabled by default because it breaks builds 212 # on many systems (where -lcrypt is needed), e.g. Linux (I believe). 213 # 214 # First, look at Setup.config; configure may have set this for you. 215 216 crypt cryptmodule.c # -lcrypt # crypt(3); needs -lcrypt on some systems ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3264> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4925] Improve error message of subprocess
New submission from Martin Mokrejs : I think the following error output unsatisfactory as it does not give me any hint what file was not found: $ fetch_quals.py blah.txt Traceback (most recent call last): File "/home/mmokrejs/bin/fetch_quals.py", line 15, in _p1 = subprocess.Popen(['query_tracedb', 'retrieve', 'quality', _id], stdin=subprocess.PIPE, stdout=subprocess.PIPE) File "/usr/lib/python2.5/subprocess.py", line 594, in __init__ errread, errwrite) File "/usr/lib/python2.5/subprocess.py", line 1091, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory $ I know now that I had to specify full path tot he binary or include shell=True argument but anyway, please improve the error message. -- components: Extension Modules messages: 79684 nosy: mmokrejs severity: normal status: open title: Improve error message of subprocess type: behavior versions: Python 2.5 ___ Python tracker <http://bugs.python.org/issue4925> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17234] python-2.7.3-r3: crash in visit_decref()
Martin Mokrejs added the comment: Hi Ramchandra and Christian, I am using numpy, matplotlib, expat/cElementTree, doing a lot of os.Popen calls. But I think the problem is taht I have huge lists and when I do not need them I do del(_mylist) in the code ASAP. That probably causes a lot of churn. Here is one stacktrace I just got with the faulthandler installed. It does not show in the trace any 3rd-party module so can I conclude it is a core python bug? Just recompiling with "-ggdb" so eventually will have better stacktraces. Does this help? I don't have the gdb stacktrace as I recompiled the binary now again ... :( Fatal Python error: /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/dictobject.c:1009 object at 0x40c0a60 has negative ref count -1 Fatal Python error: Aborted -- ___ Python tracker <http://bugs.python.org/issue17234> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689
New submission from Martin Mokrejs:
Hi,
it happened to me that using faulthandler and python compiled with
--with-pydebug and C*FLAGS=-ggdb I got this stacktrace (will attach longer
version as a file):
(gdb) where
#0 0x7f0e3af8aacb in raise () from /lib64/libpthread.so.0
#1 0x7f0e3a0b05f6 in faulthandler_fatal_error (signum=6) at
faulthandler.c:321
#2
#3 0x7f0e3ac061f5 in raise () from /lib64/libc.so.6
#4 0x7f0e3ac0766b in abort () from /lib64/libc.so.6
#5 0x7f0e3b327828 in Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
byte") at
/mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Python/pythonrun.c:1689
#6 0x7f0e3b257dc8 in _PyObject_DebugCheckAddressApi (api=111 'o',
p=0x449e6900) at
/mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/obmalloc.c:1591
#7 0x7f0e3b257a6c in _PyObject_DebugFreeApi (api=111 'o', p=0x449e6900) at
/mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/obmalloc.c:1478
#8 0x7f0e3b257913 in _PyObject_DebugFree (p=0x449e6900) at
/mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/obmalloc.c:1422
#9 0x7f0e3b34319a in PyObject_GC_Del (op=0x449e6920) at
/mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Modules/gcmodule.c:1561
#10 0x7f0e3b275ef7 in tupledealloc (op=0x449e6920) at
/mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/tupleobject.c:235
#11 0x7f0e3b255bac in _Py_Dealloc (op=(True,)) at
/mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/object.c:2262
#12 0x7f0e3b246d77 in dict_dealloc (mp=0x449b5d80) at
/mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/dictobject.c:1010
#13 0x7f0e3b255bac in _Py_Dealloc (op=
{'_label': , '_facecolors_original': (, , ), '_transform': , 'figure':
, _shorthand_name='',
_parents=, data={})
at remote 0x129fbdf8>) at remote 0xd5bb0300>,
_boxout=, _shorthand_name='',
_parents=,
data={741848704: , 405520480: , 322803328: , 3585872752: ,
_facecolors_original=(, ,
), _transform=,
figure=, _shorthand_name='',
_parents=, data={})
at remote 0x129fbdf8>) at remote 0xd5bb0300>,
_boxout=, _shorthand_name='',
_parents=,
data={741848704: , 405520480: , 322803328: , 3585872752: ,
_facecolors_original=(, ,
), _transform=,
figure=, _shorthand_name='',
_parents=, data={})
at remote 0x129fbdf8>) at remote 0xd5bb0300>,
_boxout=, _shorthand_name='',
_parents=,
data={741848704: , 405520480: , 322803328: , 3585872752: , , ),
_transform=, data={})
at remote 0x129fb510>) at remote 0x1201cd10>, figure=, _shorthand_name='',
_parents=, data={})
at remote 0x129fbdf8>) at remote 0xd5bb0300>,
_boxout=, _shorthand_name='',
_parents=, data={741848...(truncated)) at
/mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/object.c:2262
#18 0x7f0e3b245789 in insertdict_by_entry (mp=0x17e2a9c0,
key='collections', hash=567427802554420, ep=0x103a7dc0, value=[]) at
/mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/dictobject.c:519
#19 0x7f0e3b245a5b in insertdict (mp=0x17e2a9c0, key='collections',
hash=567427802554420, value=[]) at
/mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/dictobject.c:556
#20 0x7f0e3b246326 in dict_set_item_by_hash_or_entry (op=0x0,
key='collections', hash=567427802554420, ep=0x0, value=[]) at
/mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/dictobject.c:765
#21 0x7f0e3b2464be in PyDict_SetItem (
op={'transLimits': , input_dims=2,
transform_path=, transform=, transform_affine=,
inverted=,
_child=,
data={315699008: }) at remote 0x350f5df8>) at
remote 0x2c360bc0>, _x=, data={315699008: }) at remote
0xbfde2b8>) at remote 0x2c36c680>, _inverted=None, _mtx=None,
_shorthand_name='', _parents=http://bugs.python.org/file31474/bad_leading_pad_byte_14028_shortened.txt
___
Python tracker
<http://bugs.python.org/issue18843>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689
Martin Mokrejs added the comment: Should have included from the head of gdb output: Program terminated with signal 6, Aborted. -- ___ Python tracker <http://bugs.python.org/issue18843> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689
Martin Mokrejs added the comment: Would you please guide me what gdb commands I should issue for you? Thank you. BTW, I ran memtest86+ few days ago, although this is non-ECC memory I think HW is fine. -- ___ Python tracker <http://bugs.python.org/issue18843> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689
Martin Mokrejs added the comment: Grr, forgot to look into a file where I recorded STDERR. Debug memory block at address p=0x449e6900: API 'o' 80 bytes originally requested The 7 pad bytes at p-7 are not all FORBIDDENBYTE (0xfb): at p-7: 0xfb at p-6: 0xfb at p-5: 0xfa *** OUCH at p-4: 0xfb at p-3: 0xfb at p-2: 0xfb at p-1: 0xfb Because memory is corrupted at the start, the count of bytes requested may be bogus, and checking the trailing pad bytes may segfault. The 8 pad bytes at tail=0x449e6950 are FORBIDDENBYTE, as expected. The block was made by call #8155854715 to debug malloc/realloc. Data at p: 00 00 00 00 00 00 00 00 ... 20 af 5b 3b 0e 7f 00 00 Fatal Python error: bad leading pad byte Fatal Python error: Aborted Current thread 0x7f0e3b7ec700: File "/usr/lib64/python2.7/site-packages/matplotlib/axes.py", line 932 in cla File "/usr/lib64/python2.7/site-packages/matplotlib/figure.py", line 906 in clf File "/usr/lib64/python2.7/site-packages/matplotlib/figure.py", line 926 in clear File "blah.py", line 12513 in draw_hist2d_plot In that function I call: del(_series) del(_ax1) _figure.clear() # 12513 -- ___ Python tracker <http://bugs.python.org/issue18843> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689
Martin Mokrejs added the comment: Thank you for explanation what is going on. I called matplotlibs drawing function to include 49308 dots and corresponding legend items with their colors. That's all I can say. I am not a native English speaker so I don't know what 'rogue extension modules' means. Do you think it is a matplotlib or numpy issue which were in the stacktrace? Or a memory module error? I am running analyses which take weeks. Will python give me a clear warning/error when the object counter overflows? So what should I do now? I am clue-less right now. -- ___ Python tracker <http://bugs.python.org/issue18843> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18845] 2.7.5-r2: Fatal Python error: Segmentation fault
New submission from Martin Mokrejs: While running my app testsuite I have another one which crashed. Fatal Python error: Segmentation fault Current thread 0x7fe8d3527700: File "/usr/lib64/python2.7/site-packages/matplotlib/transforms.py", line 2370 in get_matrix File "/usr/lib64/python2.7/site-packages/matplotlib/transforms.py", line 2203 in get_affine File "/usr/lib64/python2.7/site-packages/matplotlib/transforms.py", line 2175 in transform_affine File "/usr/lib64/python2.7/site-packages/matplotlib/transforms.py", line 1238 in transform File "/usr/lib64/python2.7/site-packages/matplotlib/transforms.py", line 1030 in get_points File "/usr/lib64/python2.7/site-packages/matplotlib/transforms.py", line 277 in __array__ File "/usr/lib64/python2.7/site-packages/matplotlib/backends/backend_agg.py", line 110 in draw_path_collection File "/usr/lib64/python2.7/site-packages/matplotlib/collections.py", line 259 in draw File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54 in draw_wrapper File "/usr/lib64/python2.7/site-packages/matplotlib/collections.py", line 695 in draw File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54 in draw_wrapper File "/usr/lib64/python2.7/site-packages/matplotlib/axes.py", line 2086 in draw File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54 in draw_wrapper File "/usr/lib64/python2.7/site-packages/matplotlib/figure.py", line 1006 in draw File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54 in draw_wrapper File "/usr/lib64/python2.7/site-packages/matplotlib/backends/backend_agg.py", line 440 in draw File "/usr/lib64/python2.7/site-packages/matplotlib/backends/backend_agg.py", line 492 in print_png File "/usr/lib64/python2.7/site-packages/matplotlib/backend_bases.py", line 2096 in print_figure File "/usr/lib64/python2.7/site-packages/matplotlib/figure.py", line 1370 in savefig I wanted to draw 55620 dots in a scatter plot, each with a legend and its associated color. Actually only 100 color are used and multiple adjacent dots in the series have same color as necessary. Is this a matplotlib or a python error? -- files: matplotlib_crash_1676__SRR091640_shortened.txt messages: 196239 nosy: mmokrejs priority: normal severity: normal status: open title: 2.7.5-r2: Fatal Python error: Segmentation fault type: crash versions: Python 2.7 Added file: http://bugs.python.org/file31478/matplotlib_crash_1676__SRR091640_shortened.txt ___ Python tracker <http://bugs.python.org/issue18845> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689
Martin Mokrejs added the comment: Yes, I have rebuilt all python modules but even gdb exited on startup due to python ABI change. I am using Gentoo Linux (https://bugs.gentoo.org/show_bug.cgi?id=482348) and unless python-updater forgot to include some package in the listing of those needed to be recompiled, I am sane. And becuase gdb could not even start up I *hope* those no recompiled yet would NOT work AT ALL. Thanks for clarification, I thought that I might reach some internal number (the serial number as you say) in python and run out of some internal counters on objects. Actually, I hit these issues because I wondered why some of my application tests fail. Although all tests crunch a really lot of data they merely do the same in the end: draw charts using matplotlib which uses numpy. I have huge lists which I recently converted to generators (if possible) and now I even use imap(), izip(), ifilter() from itertools. One of the crashed tests has 153 levels in gdb stacktrace and few lines from the very top/outer already had the izip() objects. But the tests which crashed are not so huge like others, maybe take just 1/10 of the size of others, so I wonder why these failed. I think some crashes are related to me deleting explictly a huge list in my code even before leaving a function. Or maybe returning such lists between child/parent functions? Could valgring or something else help to find who is overwriting data of others? But I don't have experience with using it. I think this _figure.clear() crash could be manifestation of python deleting a wrong object/pointer. Some ugly for loops over lists took ... don't know how much but in total even 26GB of RAM was reserved by the process (most of it also as residual memory requirement). With itertools() I got down 10x. -- ___ Python tracker <http://bugs.python.org/issue18843> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689
Martin Mokrejs added the comment: I took a crack from another angle. I converted my application using cython and then used gcc. Finally, ran valgrind over the binary. It is not finished yet but already spotted plenty of hints. -- Added file: http://bugs.python.org/file31490/python2.7_through_cython_valgrind.txt ___ Python tracker <http://bugs.python.org/issue18843> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18850] xml.etree.ElementTree accepts control chars.
Martin Mokrejs added the comment: Incidentally I read today http://blastedbio.blogspot.co.uk/2012/05/blast-tabular-missing-descriptions.html mentioning ^A being used. Maybe that would stop working? -- nosy: +mmokrejs ___ Python tracker <http://bugs.python.org/issue18850> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689
Martin Mokrejs added the comment: No, I did not know that. Thanks, I did now. * Uncomment Py_USING_MEMORY_DEBUGGER in Objects/obmalloc.c, then rebuild Python * Uncomment the lines in Misc/valgrind-python.supp that suppress the warnings for PyObject_Free and PyObject_Realloc Why isn't there a configure switch for this? :( -- ___ Python tracker <http://bugs.python.org/issue18843> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689
Martin Mokrejs added the comment: I was just checking whether configure picked up my --with-pymalloc and incidentally saw: --with-valgrind Enable Valgrind support maybe Misc/README.valgrind needs revision and should explain what that does as well? ;-) It should also explain what is one supposed to do with Misc/valgrind-python.supp. It becomes clear once one goes to edit that file, true. ;-) -- ___ Python tracker <http://bugs.python.org/issue18843> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689
Martin Mokrejs added the comment: I wanted to move away from the --with-pydebug to a normal python and I failed with: # emerge dev-lang/python:2.7 * IMPORTANT: 11 news items need reading for repository 'gentoo'. * Use eselect news to read news items. Calculating dependencies... done! Debug memory block at address p=0xa7f5900: API 'o' 80 bytes originally requested The 7 pad bytes at p-7 are not all FORBIDDENBYTE (0xfb): at p-7: 0xfb at p-6: 0xfb at p-5: 0xfa *** OUCH at p-4: 0xfb at p-3: 0xfb at p-2: 0xfb at p-1: 0xfb Because memory is corrupted at the start, the count of bytes requested may be bogus, and checking the trailing pad bytes may segfault. The 8 pad bytes at tail=0xa7f5950 are FORBIDDENBYTE, as expected. The block was made by call #21242094 to debug malloc/realloc. Data at p: 73 00 00 00 79 00 00 00 ... 67 00 00 00 00 00 00 00 Fatal Python error: bad leading pad byte Aborted (core dumped) # Great. So, what can we gather now from this? It got overwritten within few dozens of seconds at most since I started emerge. It is in a different memory region (so no memory module HW bug). I am attaching the resolved stacktrace just in case ... -- Added file: http://bugs.python.org/file31511/core.emerge.8425.gdb.txt ___ Python tracker <http://bugs.python.org/issue18843> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689
Martin Mokrejs added the comment: One more note. At that time I had running my application which at that time was parsing an XML file using xml.parsers.expat! That is being run in my pipeline before I render figures (the initially reported crash case). So, matplotlib/numpy is ruled out. -- ___ Python tracker <http://bugs.python.org/issue18843> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689
Martin Mokrejs added the comment: Sorry, I should explain a bit more. Gentoo Linux uses a tool named emerge to handle packages. It is written in python. So, by that command I initiated re-compilation of python itself but it crashed quickly. At that moment emerge called the python available on the system at that time which was configured using --with-pydebug. Meanwhile I went to install DUMA http://duma.sourceforge.net/ and started to re-run emerge. # emerge duma # export LD_PRELOAD=/usr/lib64/libduma.so.0.0.0 # sysctl -w vm.max_map_count=100 # emerge dev-lang/python:2.7 Thanks for your analysis, will try to stitch something. -- ___ Python tracker <http://bugs.python.org/issue18843> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689
Martin Mokrejs added the comment: Thanks, will recompile without pymalloc. I don't understand why always is only 1 bit different. Could that be overwritten by another use process or do you believe it must be the python or some of the modules imported into it on runtime? -- ___ Python tracker <http://bugs.python.org/issue18843> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689
Martin Mokrejs added the comment: That is why I asked if other process can interfere. So, they are isolated on Linux, good. ;-) The crash in #msg196481 is just the emerge written in python, at the start it is resolving some graph of package dependencies ... once it resolves order of packages and prints a lot of output. so, it did not get to that before it crashed. In sum with what you said, my application running as another process should not interfere with the emerge process, so it turns out that was irrelevant comment from my side. ;) -- ___ Python tracker <http://bugs.python.org/issue18843> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689
Martin Mokrejs added the comment: http://www.gentoo.org/proj/en/portage/index.xml http://dev.gentoo.org/~zmedico/portage/archives -- ___ Python tracker <http://bugs.python.org/issue18843> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689
Martin Mokrejs added the comment:
Hi Stephen,
I discussed the USE=debug here
(https://bugs.gentoo.org/show_bug.cgi?id=482348) and it is denied by portage
maintainers because it is not only a debug addition but a whole API change. We
have to live with:
mkdir -p /etc/portage/env
echo 'EXTRA_ECONF="--with-pydebug"' > /etc/portage/env/pydebug.conf
echo dev-lang/python pydebug.conf >> /etc/portage/package.env
The above what I had originally. Yesterday I tried even:
# cat /etc/portage/env/pydebug.conf
EXTRA_ECONF="--with-pydebug --without-pymalloc --with-valgrind"
#
but I don't know what the valgrind option really does and, whether that means:
a) python will run itself under valgrind, don't both doing it yourself
b) you don't have to bother with uncommenting the lines in valgrind.supp
c) "make install" will install the valgrind.supp but you have to edit it on
your own
d) you may use valgrind but don't use other tool replacing malloc(), like
electric fence, DUMA, etc.
Or some combination of them? :( The Readme.valgrind does not answer this at all.
I let DUMA inspect "emerge boost" run overnight but my computer stopped
responding (16GB RAM).
I tried only gcc-4.7.3 and python-2.7.5-r2.
CFLAGS="-ggdb -pipe -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -msse4 -mavx
-maes -mpclmul -mpopcnt -march=corei7-avx"
CXXFLAGS="${CFLAGS}"
Per comment from Charles-François, so you mean that this single-bit change
won't be caught by valgrind, right? Why does not memtest86+ detect that? Could
python when compiled with the --with-pydebug print also physical, hardware
address of the wrong value? That would be really helpful here! Thanks.
--
___
Python tracker
<http://bugs.python.org/issue18843>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18883] python-3.3.2-r2: Modules/xxlimited.c:17:error: #error Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and Py_REF_DEBUG
New submission from Martin Mokrejs: Looks I cannot compile when python-3.3 was configured with --with-pydebug. I use Gentoo Linux, the -r2 shows they added some patches but should not matter I think. building 'xxlimited' extension x86_64-pc-linux-gnu-gcc -pthread -fPIC -Wno-unused-result -DDYNAMIC_ANNOTATIONS_ENABLED=1 -O2 -pipe -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -msse4 -mavx -maes -mpclmul -mpopcnt -march=corei7-avx -fstack-protector-all -fwrapv -DPy_LIMITED_API=1 -IInclude -I. -I/mnt/1TB/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Include -I/mnt/1TB/var/tmp/portage/dev-lang/python-3.3.2-r2/work/x86_64-pc-linux-gnu -c /mnt/1TB/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Modules/xxlimited.c -o build/temp.linux-x86_64-3.3-pydebug/mnt/1TB/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Modules/xxlimited.o In file included from /mnt/1TB/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Include/Python.h:68:0, from /mnt/1TB/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Modules/xxlimited.c:17: /mnt/1TB/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Include/object.h:65:2: error: #error Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and Py_REF_DEBUG I think make should ignore this error unless you fix xxlimited.c sources. -- files: build.log messages: 196534 nosy: mmokrejs priority: normal severity: normal status: open title: python-3.3.2-r2: Modules/xxlimited.c:17:error: #error Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and Py_REF_DEBUG type: compile error versions: Python 3.3 Added file: http://bugs.python.org/file31520/build.log ___ Python tracker <http://bugs.python.org/issue18883> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18884] python-2.7.5-r3: 40 bytes in 1 blocks are definitely lost
New submission from Martin Mokrejs: It is not important why I had in this moment matplotlib not in sync with python itself whcih was configure using --with-pydebug ... but here I just want to show that maybe you do not test for memleaks using valgrind on import errors (maybe include such testcase into you tests). Anyway, here is what I got: ==14007== Memcheck, a memory error detector ==14007== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==14007== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==14007== Command: /usr/bin/python2.7 blah.py ==14007== Traceback (most recent call last): File "blah.py", line 288, in import pylab File "/usr/lib64/python2.7/site-packages/pylab.py", line 1, in from matplotlib.pylab import * File "/usr/lib64/python2.7/site-packages/matplotlib/pylab.py", line 222, in from matplotlib import mpl # pulls in most modules File "/usr/lib64/python2.7/site-packages/matplotlib/mpl.py", line 1, in from matplotlib import artist File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 7, in from transforms import Bbox, IdentityTransform, TransformedBbox, \ File "/usr/lib64/python2.7/site-packages/matplotlib/transforms.py", line 35, in from matplotlib._path import (affine_transform, count_bboxes_overlapping_bbox, ImportError: /usr/lib64/python2.7/site-packages/matplotlib/_path.so: undefined symbol: _PyMem_DebugFree [100070 refs] ==14007== ==14007== HEAP SUMMARY: ==14007== in use at exit: 6,303,492 bytes in 31,921 blocks ==14007== total heap usage: 1,266,299 allocs, 1,234,378 frees, 179,304,947 bytes allocated ==14007== ==14007== 40 bytes in 1 blocks are definitely lost in loss record 167 of 3,515 ==14007==at 0x4C2C63B: malloc (vg_replace_malloc.c:270) ==14007==by 0x4EF1E8C: PyMem_Malloc (object.c:2343) ==14007==by 0x10064848: initialize_builtin_datetime_metadata (arraytypes.c.src:3953) ==14007==by 0x100719E2: set_typeinfo (arraytypes.c.src:4047) ==14007==by 0x1016354E: initmultiarray (multiarraymodule.c:4057) ==14007==by 0x4FB2661: _PyImport_LoadDynamicModule (importdl.c:53) ==14007==by 0x4FAE3A7: load_module (import.c:1915) ==14007==by 0x4FB07C1: import_submodule (import.c:2700) ==14007==by 0x4FAFCC6: load_next (import.c:2515) ==14007==by 0x4FAED8B: import_module_level (import.c:2224) ==14007==by 0x4FAF320: PyImport_ImportModuleLevel (import.c:2288) ==14007==by 0x4F78862: builtin___import__ (bltinmodule.c:49) -- components: Interpreter Core messages: 196538 nosy: mmokrejs priority: normal severity: normal status: open title: python-2.7.5-r3: 40 bytes in 1 blocks are definitely lost versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue18884> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18883] python-3.3.2-r2: Modules/xxlimited.c:17:error: #error Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and Py_REF_DEBUG
Martin Mokrejs added the comment: See for what I did to Gentoo: http://bugs.python.org/issue18843#msg196520 -- ___ Python tracker <http://bugs.python.org/issue18883> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18883] python-3.3.2-r2: Modules/xxlimited.c:17:error: #error Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and Py_REF_DEBUG
Martin Mokrejs added the comment: Uh. I don't understand. So did you want to say I should not run configure --with-pydebug in python 3.3 or what? I am fine if you fix the Makefile not to exit on this particular file. I am missing something. -- ___ Python tracker <http://bugs.python.org/issue18883> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18859] README.valgrind should mention --with-valgrind
Martin Mokrejs added the comment: Moreover, it should explain what that really does. One could think of several answers or even their combinations what this configure flag will really do: a) python will run itself under valgrind, don't bother ever doing it yourself b) you don't have to bother with uncommenting the lines in valgrind.supp c) "make install" will install the valgrind.supp but you have to edit it on your own d) you may use valgrind but don't use other tool replacing malloc(), like electric fence, DUMA, etc. You should be quite verbose how (in)compatible is this with other tools. Or some combination of them? valgrind docs say it won't work if a binary lacks debug symbols (wasn't compiled with -g). Initially I got mislead I though I have to convert my blah.py to blah.c using cython, compile that with "gcc -ggdb blah.c" and then I may run valgrind on the binary. In the end, I don't understand why everybody has to remove the comment symbols from the valgrind-python.supp file at all. Why isn't that by default enabled? I also suggest you mention right in the file other handy information because people quite likely get on this path while chasing memory corruption issues, maybe broken hardware: 1. Mention that python uses 256kB chunks by default. 2. Mention there exists --without-pymalloc as Tim explained me in http://bugs.python.org/issue18843#msg196492 3. Explain how to interpret those stacktraces one could get: http://bugs.python.org/issue18843#msg196481 Thank you! -- nosy: +mmokrejs ___ Python tracker <http://bugs.python.org/issue18859> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18883] python-3.3.2-r2: Modules/xxlimited.c:17:error: #error Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and Py_REF_DEBUG
Martin Mokrejs added the comment:
Hmm, but I did not add -DPy_LIMITED_API=1. Python 2.7.5 can be compiled using
same configuration. Going back to the build.log file I see:
configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
--sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 --with-fpectl
--enable-shared --disable-ipv6 --with-threads --infodir=${prefix}/share/info
--mandir=${prefix}/share/man --with-computed-gotos --with-dbmliborder=gdbm
--with-libc= --enable-loadable-sqlite-extensions --with-system-expat
--with-system-ffi --with-pydebug --without-pymalloc --with-valgrind
I specified only "--with-pydebug --without-pymalloc --with-valgrind". So where
does the limited API come from? Bug in configure.ac?
--
___
Python tracker
<http://bugs.python.org/issue18883>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18883] python-3.3.2-r2: Modules/xxlimited.c:17:error: #error Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and Py_REF_DEBUG
Martin Mokrejs added the comment: So I conclude that you want to say that some of the configure flags is wrong? Which? I can surely report that at Gentoo. I still think Makefile should be changed so that it make does not even try to compile xxlimited.c if -DPy_LIMITED_API=1 is in CFLAGS regardless how that happened. http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-lang/python/ Look into the python-3.3.2-r2.ebuild file for what it does, and how does differ from 3.7.5-r2.ebuild which can be compiled fine through emerge abd thsoe 3 configure arguments I requested. -- ___ Python tracker <http://bugs.python.org/issue18883> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18884] python-2.7.5-r3: 40 bytes in 1 blocks are definitely lost
Martin Mokrejs added the comment: Why do you think so? My point is that this happens when import fails. But python is at fault and should handle import errors. -- ___ Python tracker <http://bugs.python.org/issue18884> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18884] python-2.7.5-r3: 40 bytes in 1 blocks are definitely lost
Martin Mokrejs added the comment: Of course I did recompile matplotlib to use the recompiled python with debug ABI. I just don't understand why if something is not leaded why a memleak has to happen. Anyway, now my application using the recompiled matplotlib baffled this through valgrind as well. An there was no ImportError: ;-) ==17489== 40 bytes in 1 blocks are definitely lost in loss record 718 of 5,487 ==17489==at 0x4C2C63B: malloc (vg_replace_malloc.c:270) ==17489==by 0x4EF1E8C: PyMem_Malloc (object.c:2343) ==17489==by 0x10064848: initialize_builtin_datetime_metadata (arraytypes.c.src:3953) ==17489==by 0x100719E2: set_typeinfo (arraytypes.c.src:4047) ==17489==by 0x1016354E: initmultiarray (multiarraymodule.c:4057) ==17489==by 0x4FB2661: _PyImport_LoadDynamicModule (importdl.c:53) ==17489==by 0x4FAE3A7: load_module (import.c:1915) ==17489==by 0x4FB07C1: import_submodule (import.c:2700) ==17489==by 0x4FAFCC6: load_next (import.c:2515) ==17489==by 0x4FAED8B: import_module_level (import.c:2224) ==17489==by 0x4FAF320: PyImport_ImportModuleLevel (import.c:2288) ==17489==by 0x4F78862: builtin___import__ (bltinmodule.c:49) This is probably because I also added --without-pymalloc as you wanted. -- ___ Python tracker <http://bugs.python.org/issue18884> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18884] python-2.7.5-r3: 40 bytes in 1 blocks are definitely lost
Changes by Martin Mokrejs : Added file: http://bugs.python.org/file31523/valgrind_python275_without-pymalloc.txt ___ Python tracker <http://bugs.python.org/issue18884> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689
Martin Mokrejs added the comment: I think it would be of tremendous help if python reported the physical memory address though do not know how much work is that for you. I already said that, I wonder why memtest86+ could not find an error, I even tried other tools for that. Could --with-pydebug immediately after writing those pad bytes try to read them back, just to make sure they are readable? Theoretically one could catch the wrong bit of memory immediately. It is random, I think CPU must be fully loaded for a long while, plus something unknown has to kick in. Maybe that has to heat up the memory modules to cause the failure. My motherboard is already 3rd but doubt it is at fault, except that the SandyBridge chip is bad by design. Was replaced few days ago with CPU cooler (was the main reason for technician to come). I take that replacing motherboard was a nice offer from Dell. I would instead think that maybe CPU is heating too much. BIOS is weird. ACPI and PCIe ASPM are exploiting Linux kernel hotplug support and PCI developers are puzzled. I experience that SandyBridge resets e.g. its USB2.0 controller if there was a hotplug even on some of its other root ports (express card was inserted/ejected). But in overall I don't think it is a bad deal and it works. These exceptional glitches are I think a software error or BIOS error. It just wouldn't be running all the days and nights. No, it is not overheated, at least not now with the replaced cooler. I can put in other memory module (with which I bought the laptop from Dell). Other than that, hmm ... I could take out the hard drive and attach it to some other computer, boot from Live-DVD ... the problem is I need a lot of RAM for some of my stuff and it would have to be relatively same CPU type (I compiled binaries with avx). Yes, the emerge crash definitely was another case, I could hope to get that happen on even 1GB RAM machine, sure. I just don't have a testcase for that to trigger. I tried to stitch something but no, I probably coded something not going in the right direction. If you would have the time to stitch down some test for me to execute with the garbage collector calls, it would be probably the best. -- ___ Python tracker <http://bugs.python.org/issue18843> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689
Martin Mokrejs added the comment: So with your test program I did not yet hit the error. It used in the end 1.3GB of RAM, maybe in the good region. while this was python-2.7.5 configures as --without-pymalloc maybe the output from valgrind becomes more useful. -- Added file: http://bugs.python.org/file31532/stress.valgrind.stderr ___ Python tracker <http://bugs.python.org/issue18843> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18897] Illegal instruction at Python-2.7.5/Modules/_sre.c:1173
New submission from Martin Mokrejs:
I was trying to use DUMA to find errors in python runtime and it indeed killed
python-based utility called emerge. Let's see what you say now:
# export LD_PRELOAD=/usr/lib64/libduma.so.0.0.0
# sysctl -w vm.max_map_count=100
# emerge dev-lang/python:2.7
DUMA 2.5.15 (shared library, NO_LEAKDETECTION)
Copyright (C) 2006 Michael Eddington
Copyright (C) 2002-2008 Hayati Ayguen , Procitec GmbH
Copyright (C) 1987-1999 Bruce Perens
DUMA 2.5.15 (shared library, NO_LEAKDETECTION)
Copyright (C) 2006 Michael Eddington
Copyright (C) 2002-2008 Hayati Ayguen , Procitec GmbH
Copyright (C) 1987-1999 Bruce Perens
DUMA 2.5.15 (shared library, NO_LEAKDETECTION)
Copyright (C) 2006 Michael Eddington
Copyright (C) 2002-2008 Hayati Ayguen , Procitec GmbH
Copyright (C) 1987-1999 Bruce Perens
DUMA Aborting: mprotect() failed: Cannot allocate memory.
Check README section 'MEMORY USAGE AND EXECUTION SPEED'
if your (Linux) system may limit the number of different page mappings per
process
Illegal instruction (core dumped)
# ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 127104
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size(512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 127104
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
#
(gdb) where
#0 0x7febd6ed84d7 in kill () from /lib64/libc.so.6
#1 0x7febd78e2f9c in DUMA_Abort () from /usr/lib64/libduma.so.0.0.0
#2 0x7febd78e1b77 in _duma_allocate () from /usr/lib64/libduma.so.0.0.0
#3 0x7febd78e1fef in _duma_malloc () from /usr/lib64/libduma.so.0.0.0
#4 0x7febd7626c60 in sre_umatch (state=0x7fff96f0de10,
pattern=0x7feb2804ecb8) at
/mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Modules/_sre.c:1173
#5 0x7febd762932f in pattern_match (self=0x7feb2804ec58,
args=(u'>=gnome-base/libbonobo-2.32::gentoo-haskell',), kw=0x0) at
/mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Modules/_sre.c:1896
#6 0x7febd751ffcc in PyCFunction_Call (func=,
arg=(u'>=gnome-base/libbonobo-2.32::gentoo-haskell',), kw=0x0) at
/mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/methodobject.c:85
#7 0x7febd75c4b81 in call_function (pp_stack=0x7fff96f0e6d0, oparg=1) at
/mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Python/ceval.c:4021
#8 0x7febd75bf6c6 in PyEval_EvalFrameEx (f=Frame 0x7feb374ebce8, for file
/usr/lib64/portage/pym/portage/dep/__init__.py, line 1227, in __init__
(self=,
s=u'>=gnome-base/libbonobo-2.32::gentoo-haskell', unevaluated_atom=None,
allow_wildcard=True, allow_repo=True, _use=None, eapi=None, is_valid_flag=None,
eapi_attrs=<_eapi_attrs at remote 0x7feb31931f48>, atom_re=<_sre.SRE_Pattern at
remote 0x7feb2804ec58>, blocker_prefix=u'', blocker=False), throwflag=0) at
/mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Python/ceval.c:2666
[cut]
(gdb) bt full
#0 0x7febd6ed84d7 in kill () from /lib64/libc.so.6
No symbol table info available.
#1 0x7febd78e2f9c in DUMA_Abort () from /usr/lib64/libduma.so.0.0.0
No symbol table info available.
#2 0x7febd78e1b77 in _duma_allocate () from /usr/lib64/libduma.so.0.0.0
No symbol table info available.
#3 0x7febd78e1fef in _duma_malloc () from /usr/lib64/libduma.so.0.0.0
No symbol table info available.
#4 0x7febd7626c60 in sre_umatch (state=0x7fff96f0de10,
pattern=0x7feb2804ecb8) at
/mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Modules/_sre.c:1173
end = 0x7fea931cfffc
alloc_pos = 1648
ctx_pos = 1648
i = 128
ret = 0
jump = 2
sigcount = 187
ctx = 0x7fea931fbcf8
nextctx = 0x7fea931fbcf8
__PRETTY_FUNCTION__ = "sre_umatch"
#5 0x7febd762932f in pattern_match (self=0x7feb2804ec58,
args=(u'>=gnome-base/libbonobo-2.32::gentoo-haskell',), kw=0x0) at
/mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Modules/_sre.c:1896
state = {ptr = 0x7fea931cffbc, beginning = 0x7fea931cff50, start =
0x7fea931cff50, end = 0x7fea931cfffc, string =
u'>=gnome-base/libbonobo-2.32::gentoo-haskell', pos = 0, endpos = 43, charsize
= 4, lastindex = 2, lastmark = 43, mark = {0x7fea931cff50, 0x0, 0x7fea931cff50,
0x7fea931cffbc, 0x7fea931cff50, 0x7fea931cff58, 0x7fea931cff58, 0x7fea931cffbc,
0x7fea931cff58, 0x7fe
[issue18897] Illegal instruction at Python-2.7.5/Modules/_sre.c:1173
Martin Mokrejs added the comment: To a naive user two places with numbers are in the stacktrace: size = -1282872823 and instr_ub = -1 instr_lb = 0 instr_prev = -1 -- ___ Python tracker <http://bugs.python.org/issue18897> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18897] Illegal instruction at Python-2.7.5/Modules/_sre.c:1173
Martin Mokrejs added the comment: I was actually printing every 10 seconds how much memory it was using, the last before got killed was: PIDVSZ RSS TIME ELAPSED %CPU %MEM COMMAND 4097 4938188 2445712 00:22:4425:04 90.7 15.0 /usr/bin/python2.7 /usr/bin/emerge dev-lang/python:2.7 Provided I have 16GB RAM then maybe it was really some limit in the Bourne shell or OS which prevented DUMA to obtain more memory. But my own python-based app can can grow to even 12GB RSS on this computer so I wonder what limit would be the cause. Probably some overhead due to DUMA. I increased shell limits and looks it can continue further so far: vostro crashtest # ulimit -l unlimited vostro crashtest # ulimit -s unlimited vostro crashtest # ulimit -i unlimited vostro crashtest # vostro crashtest # ulimit -a core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) unlimited cpu time (seconds, -t) unlimited max user processes (-u) 127104 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited # Currently the emerge through DUMA is at: PIDVSZ RSS TIME ELAPSED %CPU %MEM COMMAND 9528 6121764 3041960 00:34:1656:05 61.1 18.6 /usr/bin/python2.7 /usr/bin/emerge dev-lang/python:2.7 and still continues ... Sorry, should better read the main STDERR output before diving into gdb stacktraces. I thought those negative numbers are a true sign of an error. ;) -- ___ Python tracker <http://bugs.python.org/issue18897> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17628] str==str: compare the first character before calling memcmp()
Martin Mokrejs added the comment: Regarding benchmarking and code performance inspection, maybe you want to try on your linux box: perf top perf stat /usr/bin/python mytest.py http://perf.wiki.kernel.org/ -- nosy: +mmokrejs ___ Python tracker <http://bugs.python.org/issue17628> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15416] 3 * [] gives a list of 3 cross-referenced lists, a[1]='blash
New submission from Martin Mokrejs :
Hi,
I thought that I can easily create a list of, say 3, nested lists:
$ python
Python 2.7.3 (default, May 17 2012, 21:10:41)
[GCC 4.5.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 3 * [[]]
[[], [], []]
>>> a=3 * [[]]
>>> a[0]
[]
>>> a[1].append('sdds')
>>> a
[['sdds'], ['sdds'], ['sdds']]
>>> a[0].append('xxx')
>>> a
[['sdds', 'xxx'], ['sdds', 'xxx'], ['sdds', 'xxx']]
The below works as expected.
>>> a=[[], [], []]
>>> a
[[], [], []]
>>> a[0]
[]
>>> a[1]
[]
>>> a[1].append('sdds')
>>> a[0].append('xxx')
>>> a
[['xxx'], ['sdds'], []]
>>>
Of course, I want to do like:
a = len(b) * [] # to get a list of individual hashes
c = len(b) * [0] # to get a list of indvidual counters
--
components: None
messages: 166081
nosy: mmokrejs
priority: normal
severity: normal
status: open
title: 3 * [] gives a list of 3 cross-referenced lists, a[1]='blash
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue15416>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15416] 3 * [] gives a list of 3 cross-referenced lists, a[1]='blah' writes in to ALL three!
Changes by Martin Mokrejs : -- title: 3 * [] gives a list of 3 cross-referenced lists, a[1]='blash -> 3 * [] gives a list of 3 cross-referenced lists, a[1]='blah' writes in to ALL three! ___ Python tracker <http://bugs.python.org/issue15416> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15416] 3 * [] gives a list of 3 cross-referenced lists, a[1]='blah' writes in to ALL three!
Martin Mokrejs added the comment: For the sake of internet archives, the following could be included in the FAQ you referred to: http://www.scipy.org/Cookbook/BuildingArrays >>> import numpy as np >>> a=np.array(5*[False],bool) >>> a array([False, False, False, False, False], dtype=bool) >>> a[4]=1 >>> a array([False, False, False, False, True], dtype=bool) >>> But thanks for the link, it helped me at that time. -- ___ Python tracker <http://bugs.python.org/issue15416> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18897] Illegal instruction at Python-2.7.5/Modules/_sre.c:1173
Martin Mokrejs added the comment: The issue could have been caused the malfunctioning memory or CPU. http://bugs.python.org/issue18843#msg204954 -- ___ Python tracker <http://bugs.python.org/issue18897> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689
Martin Mokrejs added the comment: Hi, I think I should report back what I found on the hardware side. While memory testing tools like memtest86+ and other did not find any error, the built in Dell ePSA test suite likely does compute a checksum of tested memory regions. It reported some addresses/regions as failed, sadly nobody seems to know details of the failing tests. On repeated testing different memory regions were reported, so I never understood whether that is a bad CPU cache or something randomizing the issue observed. At least, only one of the two SO-DIMMs caused the problems so lets conclude it was partly baked up and failing randomly. At that time it seemed the cause was either bad CPU producing just too much heat or the fan. Fan was replaced, max temps went down from 92 oC to 82 oC. Two months later I faced more and more often that an external HDMI-connected display did not receive signal, so even the CPU got replaced. I got another drop in max temperatures, now max are about 70 oC. Cool! Back to python, the random crashes of my apps stopped after the memory module being replaced, actually who pair was replaced. I started to dream about linux kernel making mirroring inside memory for failure resiliency but there is nothing like that available. In summary, this lesson was hard and showed that there are no good tools to test hardware. Checksums should be used always and bits tested for fading over the time. The mirroring trick could have also uncovered a failing memory or CPU. Seems there is still way to go to a perfect computer. Thanks to everybody for their efforts on this issue. Whether python takes something from this lesson is up to you. -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue18843> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18845] 2.7.5-r2: Fatal Python error: Segmentation fault
Martin Mokrejs added the comment: The issue could have been caused the malfunctioning memory or CPU. http://bugs.python.org/issue18843#msg204954 -- ___ Python tracker <http://bugs.python.org/issue18845> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27480] Cannot link _crypt and _nis modules on a host with glibc-2.12
New submission from Martin Mokrejs: Hi, it seems at least python 3.4.3-r5 on a Gentoo Linux. Failed to build these modules: _cryptnis -- files: build.log messages: 270163 nosy: mmokrejs priority: normal severity: normal status: open title: Cannot link _crypt and _nis modules on a host with glibc-2.12 type: compile error versions: Python 3.4 Added file: http://bugs.python.org/file43684/build.log ___ Python tracker <http://bugs.python.org/issue27480> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27480] Cannot link _crypt and _nis modules on a host with glibc-2.12
Martin Mokrejs added the comment: Also is an issue with 3.5.1-r3: x86_64-pc-linux-gnu-gcc -pthread -shared -Wl,-O1 -L. -L/scratch/mmokrejs/gentoo/lib -L/scratch/mmokrejs/gentoo/usr/lib -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -O2 -pipe -O2 -pipe -march=native -fwrapv build/temp.linux-x86_64-3.5/scratch/mmokrejs/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/_decimal.o build/temp.linux-x86_64-3.5/scratch/mmokrejs/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/libmpdec/basearith.o build/temp.linux-x86_64-3.5/scratch/mmokrejs/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/libmpdec/constants.o build/temp.linux-x86_64-3.5/scratch/mmokrejs/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/libmpdec/context.o build/temp.linux-x86_64-3.5/scratch/mmokrejs/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/libmpdec/convolute.o build/temp.linux-x86_64-3.5/scratch/mmokre js/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/libmpdec/crt.o build/temp.linux-x86_64-3.5/scratch/mmokrejs/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/libmpdec/difradix2.o build/temp.linux-x86_64-3.5/scratch/mmokrejs/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/libmpdec/fnt.o build/temp.linux-x86_64-3.5/scratch/mmokrejs/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/libmpdec/fourstep.o build/temp.linux-x86_64-3.5/scratch/mmokrejs/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/libmpdec/io.o build/temp.linux-x86_64-3.5/scratch/mmokrejs/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/libmpdec/memory.o build/temp.linux-x86_64-3.5/scratch/mmokrejs/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/libmpdec/mpdecimal.o build/temp.linux-x8 6_64-3.5/scratch/mmokrejs/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/libmpdec/numbertheory.o build/temp.linux-x86_64-3.5/scratch/mmokrejs/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/libmpdec/sixstep.o build/temp.linux-x86_64-3.5/scratch/mmokrejs/gentoo/var/tmp/portage/dev-lang/python-3.5.1-r3/work/Python-3.5.1/Modules/_decimal/libmpdec/transpose.o -L. -L/scratch/mmokrejs/gentoo/lib -L/scratch/mmokrejs/gentoo/usr/lib -lpython3.5 -o build/lib.linux-x86_64-3.5/_decimal.cpython-35-x86_64-linux-gnu.so *** WARNING: renaming "_crypt" since importing it failed: build/lib.linux-x86_64-3.5/_crypt.cpython-35-x86_64-linux-gnu.so: undefined symbol: crypt *** WARNING: renaming "nis" since importing it failed: build/lib.linux-x86_64-3.5/nis.cpython-35-x86_64-linux-gnu.so: undefined symbol: yp_master Following modules built successfully but were removed because they could not be imported: _cryptnis -- ___ Python tracker <http://bugs.python.org/issue27480> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27480] Cannot link _crypt and _nis modules on a host with glibc-2.12
Changes by Martin Mokrejs : -- versions: +Python 3.5 ___ Python tracker <http://bugs.python.org/issue27480> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27480] Cannot link _crypt and _nis modules on a host with glibc-2.12
Martin Mokrejs added the comment: Ah, thank you for a quick answer. The problem is not with a Gentoo, the problem is with python which needs too new libc or libnss or libcrypt. I am re-opening, why cannot I compile newer python version on glibc-2.12 host? This is not a problme with python-2.7, at least. https://bugs.gentoo.org/show_bug.cgi?id=587664 -- status: closed -> open ___ Python tracker <http://bugs.python.org/issue27480> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27480] Cannot link _crypt and _nis modules on a host with glibc-2.12
Martin Mokrejs added the comment: Interesting, using the system-wide RedHat stuff I can compile vanilla Python-3.4.5. See attached nohup.out. I tried to stick to the same configure arguments as Gentoo's package manager used. I also tried to compile the vanilla tarball under Gentoo::Prefix and wow, it also went through (as fat as _crypt is concerned). See nohup-gentoo-prefix.out -- Added file: http://bugs.python.org/file43692/nohup.out ___ Python tracker <http://bugs.python.org/issue27480> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27480] Cannot link _crypt and _nis modules on a host with glibc-2.12
Changes by Martin Mokrejs : Added file: http://bugs.python.org/file43693/nohup-gentoo-prefix.out ___ Python tracker <http://bugs.python.org/issue27480> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17207] string format precision misbehaving
New submission from Martin Mokrejs:
Hi,
I don't know if this is related to issue8040 or not. I find the 2.7 string
formatting behavior inconsistent. I found out sometimes I have to divide my
number by 100 so that the percentage values get printed correctly. Somehow,
when a percent sign appears in the formatting "definition" python magically
multiplies the number by 100. But sometimes not. This is not specified in
http://docs.python.org/2/library/stdtypes.html#string-formatting so I really do
not like this whole thing, sorry to say that.
Some examples, which should have been posted in the Library reference doc above.
$ python
Python 2.7.3 (default, Dec 19 2012, 00:02:12)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> "%s" % 12.77
'12.77'
>>> "%s" % '{:.2%}'.format(12.77)
'1276.67%'
>>> "%s" % '{:.2%}'.format(float(12.77))
'1276.67%'
>>>
>>> "%s" % ( '{:.4%}'.format(12.77) )
'1276.6667%'
>>> "%s" % ( '{:.4}'.format(12.77) )
'12.77'
>>> "%s" % ( '{:.2}'.format(12.77) )
'1.3e+01'
>>> "%s%%" % ( '{:.2}'.format(12.77) )
'1.3e+01%'
>>> "%s%%" % ( '{:.2}'.format('12.77') )
'12%'
>>> "%s%%" % ( '{:.4}'.format(float(12.77)) )
'12.77%'
>>>
>>> "%s" % ( '{:.2%}'.format(1/10) )
'0.00%'
>>> "%s" % ( '{:.2%}'.format(1/10.0) )
'10.00%'
>>> "%s" % ( '{:.2%}'.format(1/10.0 * 100) )
'1000.00%'
>>> "%s" % ( '{:.2%}'.format((1/10.0) * 100) )
'1000.00%'
>>>
>>> "%s" % ( '{:.2}'.format((1/10.0) * 100) )
'1e+01'
>>> "%s" % ( '{:.2%}'.format((1/10.0) * 100) )
'1000.00%'
>>>
1) Would somebody please document the behavior?
2) Would somebody explain how can I print 12.67% (I want precision of 2 places
after the decimal dot).
3) Why sometimes using float() fixes the behavior (likely converting int() to
float()?
4) But why does the scientific exponential notation sometimes come out?
5) Finally, it would be nice if the python 2.7 docs contained how to format
floats to 2 places after the dot using the "old" syntax":
"float=%f" % (12.77)
I would like to get just "12.77" out. I can use round() but that is not what I
am asking for. I want to change just the formatting of the output:
>>> round(12.77, 2)
12.77
>>>
Thank you
--
components: ctypes
messages: 182125
nosy: mmokrejs
priority: normal
severity: normal
status: open
title: string format precision misbehaving
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue17207>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17234] python-2.7.3-r3: crash in visit_decref()
New submission from Martin Mokrejs: Hi, I do see relatively often a crash in python. Here is one stacktrace from my Gentoo Linux running 3.7.4 kernel: (gdb) where #0 0x7f624f340f08 in visit_decref () from /usr/lib64/libpython2.7.so.1.0 #1 0x7f624f2a455a in list_traverse () from /usr/lib64/libpython2.7.so.1.0 #2 0x7f624f3412c7 in collect () from /usr/lib64/libpython2.7.so.1.0 #3 0x7f624f341f11 in _PyObject_GC_Malloc () from /usr/lib64/libpython2.7.so.1.0 #4 0x7f624f2cdd59 in PyType_GenericAlloc () from /usr/lib64/libpython2.7.so.1.0 #5 0x7f624f2d09c3 in type_call () from /usr/lib64/libpython2.7.so.1.0 #6 0x7f624f27bdc3 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0 #7 0x7f624f310d76 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0 #8 0x7f624f31285e in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0 #9 0x7f624f313905 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0 #10 0x7f624f313a32 in PyEval_EvalCode () from /usr/lib64/libpython2.7.so.1.0 #11 0x7f624f32d97c in run_mod () from /usr/lib64/libpython2.7.so.1.0 #12 0x7f624f32e53d in PyRun_StringFlags () from /usr/lib64/libpython2.7.so.1.0 #13 0x7f624f30a44e in builtin_eval () from /usr/lib64/libpython2.7.so.1.0 #14 0x7f624f312456 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0 #15 0x7f624f313905 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0 #16 0x7f624f2a104c in function_call () from /usr/lib64/libpython2.7.so.1.0 #17 0x7f624f27bdc3 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0 #18 0x7f624f28a82f in instancemethod_call () from /usr/lib64/libpython2.7.so.1.0 #19 0x7f624f27bdc3 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0 #20 0x7f624f30c9b7 in PyEval_CallObjectWithKeywords () from /usr/lib64/libpython2.7.so.1.0 #21 0x7f624612f807 in call_with_frame.isra.9 () from /usr/lib64/python2.7/lib-dynload/pyexpat.so #22 0x7f6246132080 in my_StartElementHandler () from /usr/lib64/python2.7/lib-dynload/pyexpat.so #23 0x7f6245ed0fb0 in doContent () from /usr/lib64/libexpat.so.1 #24 0x7f6245ed21b4 in contentProcessor () from /usr/lib64/libexpat.so.1 #25 0x7f6245ecce2a in XML_ParseBuffer () from /usr/lib64/libexpat.so.1 #26 0x7f6246132d5b in xmlparse_Parse () from /usr/lib64/python2.7/lib-dynload/pyexpat.so #27 0x7f624f312456 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0 #28 0x7f624f296379 in gen_send_ex.isra.1 () from /usr/lib64/libpython2.7.so.1.0 #29 0x7f624f2ce40f in wrap_next () from /usr/lib64/libpython2.7.so.1.0 #30 0x7f624f27bdc3 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0 #31 0x7f624f310d76 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0 #32 0x7f624f31285e in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0 #33 0x7f624f31285e in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0 #34 0x7f624f31285e in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0 #35 0x7f624f31285e in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0 #36 0x7f624f313905 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0 #37 0x7f624f313a32 in PyEval_EvalCode () from /usr/lib64/libpython2.7.so.1.0 #38 0x7f624f32d97c in run_mod () from /usr/lib64/libpython2.7.so.1.0 #39 0x7f624f32e750 in PyRun_FileExFlags () from /usr/lib64/libpython2.7.so.1.0 #40 0x7f624f32f1cf in PyRun_SimpleFileExFlags () from /usr/lib64/libpython2.7.so.1.0 #41 0x7f624f3407e2 in Py_Main () from /usr/lib64/libpython2.7.so.1.0 #42 0x7f624ec8f91d in __libc_start_main () from /lib64/libc.so.6 #43 0x0040094d in _start () (gdb) -- messages: 182371 nosy: mmokrejs priority: normal severity: normal status: open title: python-2.7.3-r3: crash in visit_decref() type: crash versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue17234> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25964] optparse.py:1668: (file) shadows builtin
New submission from Martin Mokrejs: I use pychecker for checking my python code. Seems optparse.py distributed with python-2.7 could be improved as well: [system path]/optparse.py:1191: Function (__init__) has too many arguments (11) [system path]/optparse.py:1206: Local variable (version) shadows global defined on line 10 in file my-test-code.py [system path]/optparse.py:1400: Local variable (stop) not used [system path]/optparse.py:1668: (file) shadows builtin Interestingly, my version variable is overridden by one from optparse.py. But more worrisome is the 'file' variable name. -- messages: 257110 nosy: mmokrejs priority: normal severity: normal status: open title: optparse.py:1668: (file) shadows builtin type: enhancement versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue25964> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25965] decimal.py: issues reprted by pychecker
New submission from Martin Mokrejs:
I use pychecker to check my code. It complains about decimal.py from
python-2.7.10 itself:
[system path]/decimal.py:1345: INTERNAL ERROR -- STOPPED PROCESSING FUNCTION --
Traceback (most recent call last):
File "/usr/lib64/python2.7/site-packages/pychecker/warn.py", line
242, in _checkFunction
_checkCode(code, codeSource)
File "/usr/lib64/python2.7/site-packages/pychecker/warn.py", line
155, in _checkCode
raise NotImplementedError('No DISPATCH member for op %r' % op)
NotImplementedError: No DISPATCH member for op 28
[system path]/decimal.py:1546: Invalid arguments to (__floordiv__), got 3,
expected 2
[system path]/decimal.py:1574: Invalid arguments to (__rfloordiv__), got 3,
expected 2
[system path]/decimal.py:1997: INTERNAL ERROR -- STOPPED PROCESSING FUNCTION --
Traceback (most recent call last):
File "/usr/lib64/python2.7/site-packages/pychecker/warn.py", line
242, in _checkFunction
_checkCode(code, codeSource)
File "/usr/lib64/python2.7/site-packages/pychecker/warn.py", line
155, in _checkCode
raise NotImplementedError('No DISPATCH member for op %r' % op)
NotImplementedError: No DISPATCH member for op 28
[system path]/decimal.py:2173: Invalid arguments to (__pow__), got 4, expected 3
[system path]/decimal.py:2389: Invalid arguments to (__rpow__), got 3, expected
2
[system path]/decimal.py:2692: INTERNAL ERROR -- STOPPED PROCESSING FUNCTION --
Traceback (most recent call last):
File "/usr/lib64/python2.7/site-packages/pychecker/warn.py", line
242, in _checkFunction
_checkCode(code, codeSource)
File "/usr/lib64/python2.7/site-packages/pychecker/warn.py", line
155, in _checkCode
raise NotImplementedError('No DISPATCH member for op %r' % op)
NotImplementedError: No DISPATCH member for op 28
--
components: Library (Lib)
messages: 257111
nosy: mmokrejs
priority: normal
severity: normal
status: open
title: decimal.py: issues reprted by pychecker
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue25965>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25965] decimal.py: issues reported by pychecker
Changes by Martin Mokrejs : -- title: decimal.py: issues reprted by pychecker -> decimal.py: issues reported by pychecker ___ Python tracker <http://bugs.python.org/issue25965> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25964] optparse.py:1668: (file) shadows builtin
Martin Mokrejs added the comment: But couldn't somebody just rename the variable for example to _file? I see optparse also in python-3.5 so I did not think it could be Deprecated. -- ___ Python tracker <http://bugs.python.org/issue25964> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
