[issue37990] gc.collect prints debug stats incorrectly
New submission from Hubert : Example: Python 3.9.0a0 (heads/master:39d87b5471, Aug 30 2019, 23:19:13) [GCC 9.1.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import gc >>> gc.set_debug(gc.DEBUG_STATS) >>> gc.collect() gc: collecting generation 2... gc: objects in each generation: 589 4120 0 gc: objects in permanent generation: 0 gc: done, 0 unreachable, 0 uncollectable, %.4fs elapsed 0 -- components: Interpreter Core messages: 350890 nosy: chivay priority: normal severity: normal status: open title: gc.collect prints debug stats incorrectly versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue37990> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47072] Database corruption with the shelve module
New submission from Hubert Tournier : After adding a few records, the shelve module corrupts the database keys (the database is still readable if an element key is known, but no more iterable): Traceback (most recent call last): File "./shelve-test.py", line 81, in _verify_whois_cache() File "./shelve-test.py", line 61, in _verify_whois_cache for key in db.keys(): File "/usr/local/lib/python3.8/_collections_abc.py", line 720, in __iter__ yield from self._mapping File "/usr/local/lib/python3.8/shelve.py", line 95, in __iter__ for k in self.dict.keys(): SystemError: Negative size passed to PyBytes_FromStringAndSize I provide a short test program and data that systematically reproduces the bug. I added the a script showing execution messages, the resulting database in DB and text formats. Tested with Python 3.8.12 on FreeBSD 13.0-RELEASE-p8. I suppose Python is using my system package db5-5.3.28_8 (Oracle Berkeley DB, revision 5.3). See also similar issues: https://bugs.python.org/issue33074 https://bugs.python.org/issue30388 -- components: Library (Lib) files: shelve-test.zip messages: 415625 nosy: HubTou priority: normal severity: normal status: open title: Database corruption with the shelve module type: behavior versions: Python 3.8 Added file: https://bugs.python.org/file50693/shelve-test.zip ___ Python tracker <https://bugs.python.org/issue47072> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47072] Database corruption with the shelve module
Hubert Tournier added the comment: Hello, Same results with Python 3.10.4: [...] Adding 185.220.102.6 Database has 62 records for 442368 bytes. Last record was 640 bytes long Traceback (most recent call last): File "./shelve-test.py", line 84, in _verify_whois_cache() File "./shelve-test.py", line 63, in _verify_whois_cache for key in db.keys(): File "/usr/local/lib/python3.10/_collections_abc.py", line 881, in __iter__ yield from self._mapping File "/usr/local/lib/python3.10/shelve.py", line 95, in __iter__ for k in self.dict.keys(): SystemError: Negative size passed to PyBytes_FromStringAndSize # freebsd-version -uk 13.0-RELEASE-p8 13.0-RELEASE-p10 # python3.10 --version Python 3.10.4 The point at which the database breaks depends (from 50 to 500+ records), the size of the database doesn't seem to be relevant (from 400K to 1800K). The size of the record *apparently* doesn't seem to be relevant (but I'm not 100% sure it's the right figure), though I've had other shelve module uses without issues with many more records but much smaller and less complex. -- Added file: https://bugs.python.org/file50703/shelve-test-3.10.zip ___ Python tracker <https://bugs.python.org/issue47072> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47072] Database corruption with the shelve module
Hubert Tournier added the comment: I modified the test program to better reflect the size of the data structures stored in shelve (sys.getsizeof() which I used was far off the real size). I saw that the database was corrupted with big records, though even bigger previous records had not corrupted it. Records larger than 1K (mentioned in one of the other problem report) were routinely OK. Records larger than 4K (also mentioned on another PR) were sometimes OK. When I took a problematic record and used it single alone or with few other records, no corruption occurred. Any idea? -- Added file: https://bugs.python.org/file50704/shelve-test-3.10-b.zip ___ Python tracker <https://bugs.python.org/issue47072> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47072] Database corruption with the shelve module
Hubert Tournier added the comment: Additional note: the test code WORKS under Windows 8.1 / Python 3.9.1 (though the data file is suffixed .dat instead of .db) resulting in a 4 MB database with 1065 records, some of them > 11 KB. So maybe the bug is system dependent. -- components: +FreeBSD nosy: +koobs versions: +Python 3.10 ___ Python tracker <https://bugs.python.org/issue47072> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47072] Database corruption with the shelve module
Hubert Tournier added the comment: The storage format used under Windows is completely different from the one used under Unix (or *BSD). Apart from the .dat datafile, there is a .dir index file with CSV lines such as "'key', (offset, length)". Whereas under Unix (or *BSD), I have: # file whois_cache.db whois_cache.db: Berkeley DB 1.85 (Hash, version 2, native byte-order) I'll make a test on a Linux Raspberry Pi, to see if the issue is *BSD specific... -- ___ Python tracker <https://bugs.python.org/issue47072> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37990] gc.collect prints debug stats incorrectly
Change by Hubert Jasudowicz : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue37990> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39710] "will be returned as unicode" reminiscent from Python 2
Change by Hubert Badocha : -- nosy: +badochov nosy_count: 9.0 -> 10.0 pull_requests: +25547 pull_request: https://github.com/python/cpython/pull/26985 ___ Python tracker <https://bugs.python.org/issue39710> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38731] bad input crashes py_compile library
Hubert Pineault added the comment: The bug is still there in python 3.8.4rc1 It has nothing to do with the doc. As pointed by Kaoru, it is introduced in line 200 of commit 2e33ecd7c9b0cac3efc6fcbdd4547fd086b4e2d1 see this comment, also by Kaoru: https://github.com/python/cpython/commit/2e33ecd7c9b0cac3efc6fcbdd4547fd086b4e2d1#r35842880 -- nosy: +hubide versions: -Python 3.9 ___ Python tracker <https://bugs.python.org/issue38731> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38731] bad input crashes py_compile library
Hubert Pineault added the comment: Thanks Joannah, I confirm this is a duplicate of https://bugs.python.org/issue40456 The issue is better tracked in 40456, so you can close here. -- ___ Python tracker <https://bugs.python.org/issue38731> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33230] _decimal build failure (unsupported platform for that module) - evolution possible?
New submission from Hubert Holin : _decimal fails to build on my platform due to lack of support: In file included from /Developer/Python/3.6/Python/Python-3.6.5/Modules/_decimal/_decimal.c:34: /usr/local/include/mpdecimal.h:201:4: error: "unsupported platform: need mpd_size_t == mpd_uint_t" #error "unsupported platform: need mpd_size_t == mpd_uint_t" My host system type: x86_64-apple-darwin17.5.0 My target system type: x86_64-apple-darwin17.5.0 Compiler used: clang+llvm-6.0.0-x86_64-apple-darwin Hardware: 3,7 GHz Quad-Core Intel Xeon E5 Relevant configurations: --enable-universalsdk... /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk --with-universal-archs... intel MACHDEP... darwin Could this module be upgraded? -- components: Extension Modules messages: 314976 nosy: Hubert Holin priority: normal severity: normal status: open title: _decimal build failure (unsupported platform for that module) - evolution possible? type: compile error versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue33230> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33230] _decimal build failure (unsupported platform for that module) - evolution possible?
Hubert Holin added the comment: This is correct: I had an older version of mpdecimal in /usr/local. However, when removed mpdecimal is (manually) removed from /usr/local (the libs and the header), making a "make clean", a config and make, the _decimal build still fails, but this time for a different reason: /Developer/Python/3.6/Python/Python-3.6.5/Modules/_decimal/_decimal.c:34:10: fatal error: 'mpdecimal.h' file not found #include "mpdecimal.h" Still, we are getting closer: should I install a newer version of mpdecimal and try again? -- ___ Python tracker <https://bugs.python.org/issue33230> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33230] _decimal build failure (unsupported platform for that module) - evolution possible?
Hubert Holin added the comment: Yes, the error turned out to be that I had indeed forgotten to remove the --with-system-libmpdec along with the library and header. Now _decimal compiles fine. I will see if I can get Python to run with my system's mpdecimal (once I have updated it), but as far as this issue is concerned I believe it is indeed closed. Thanks for the help! -- ___ Python tracker <https://bugs.python.org/issue33230> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43473] Junks in difflib
New submission from Hubert Bonnisseur-De-La-Bathe : Reading first at the documentation of difflib, I thought that the use of junks would have produced the result s = SequenceMatcher(lambda x : x == " ", "abcd efgh", "abcdefgh") s.get_matching_blocks() >>> [Match(a=0, b=0, size=8)] At a second lecture, it is clear that such evaluation will return in fact two matches of length 4. Would it be nicer to have get_matching_block return the length 8 match ? Don't know if it's in the spirit of the lib, I'm just asking. -- assignee: docs@python components: Documentation messages: 388491 nosy: docs@python, hubertbdlb priority: normal severity: normal status: open title: Junks in difflib type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue43473> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
