[issue31762] Issue in login
New submission from Nikhil : I have included the screen shot -- files: Screenshot_20171011_222848.png messages: 304164 nosy: Nik101 priority: normal severity: normal status: open title: Issue in login Added file: https://bugs.python.org/file47213/Screenshot_20171011_222848.png ___ Python tracker <https://bugs.python.org/issue31762> __ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31765] BUG: System deadlocks performing big loop operations in python 3.5.4, windows 10
New submission from Nikhil : What I did 1) root file declared where operation will start and import hashlib for getting hash signatures 2) os.walk for recursively diving into directory tree 3) open file and find sha256 digest and print it 4) close the file 5) recursively repeat all above 2 steps till we traversed directory tree Above logic python program caused sudden exponential increase in RAM usage (task manager by chance) and certainly DEADLOCK and.. Force shutdown I want to know what went wrong. -- messages: 304173 nosy: Nik101 priority: normal severity: normal status: open title: BUG: System deadlocks performing big loop operations in python 3.5.4, windows 10 ___ Python tracker <https://bugs.python.org/issue31765> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38705] venv creation on macOS Catalina is failing
Nikhil Benesch added the comment:
This issue continues to exist with the system Python on macOS. Here is how to
reproduce on macOS Catalina 10.15.7 and Xcode 12.1.
$ /usr/bin/python3 --version
Python 3.8.2
$ /usr/bin/python3 -c 'import venv; venv.create("venv");'
$ venv/bin/python3
dyld: Library not loaded: @executable_path/../Python3
Referenced from: /Users/benesch/venv/bin/python3
Reason: image not found
Abort trap: 6
Weird, isn't it? The thing that gets copied into the venv is just a totally
different file than /usr/bin/python3:
$ ls -lah venv/bin/python3
-rwxr-xr-x 1 benesch staff 148K Oct 26 23:16 venv/bin/python3
$ ls -lah /usr/bin/python3
-rwxr-xr-x 1 root wheel 31K Sep 21 20:29 /usr/bin/python3
I assume this is Apple's bug, but I'll be damned if I have to file another
report into the blackhole that is radar. If someone needs a quick workaround,
just create your venvs with symlinks, which works just fine:
$ /usr/bin/python3 -c 'import venv; venv.create("venv2");'
$ venv2/bin/python3
Python 3.8.2 (default, Sep 24 2020, 19:37:08)
[Clang 12.0.0 (clang-1200.0.32.21)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
Incidentally this is why `/usr/bin/python3 -m venv` works just fine, since it
defaults to `symlinks=True` on macOS.
--
nosy: +benesch
___
Python tracker
<https://bugs.python.org/issue38705>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38705] venv creation on macOS Catalina is failing
Nikhil Benesch added the comment:
Oops, sorry, I forgot to actually include the correct command in the
workaround. Here it is:
$ /usr/bin/python3 -c 'import venv; venv.create("venv2", symlinks=True);'
--
___
Python tracker
<https://bugs.python.org/issue38705>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38705] venv creation on macOS Catalina is failing
Nikhil Benesch added the comment: So it looks like /usr/bin/python3 is just a shim that immediately execs the real Python binary: /Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/bin/python3 This binary is identical to the one that ends up in the venv. Problematically, this binary is dynamically linked, and links the "Python3" shared library using a relative path: $ otool -L /Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/bin/python3 /Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/bin/python3: @executable_path/../Python3 (compatibility version 3.8.0, current version 3.8.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.0.0) So obviously copying that binary to a different path breaks the @executable_path-relative link. Ah, well. Definitely seems like Apple's bug. Not sure there is anything that even could be done on the CPython side. -- ___ Python tracker <https://bugs.python.org/issue38705> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25237] Add doc for tkinter commondialog.Dialog and subclasses
Changes by Nikhil Patel : -- pull_requests: +1953 ___ Python tracker <http://bugs.python.org/issue25237> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25237] Add doc for tkinter commondialog.Dialog and subclasses
Nikhil Patel added the comment: I've written rst files containing documentation for the tkinter modules and submitted a PR. Attempted to mimic the wording as well as style of existing documentation to keep it consistent. -- nosy: +npatel ___ Python tracker <http://bugs.python.org/issue25237> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30542] [EASY] test_files() of test_tools.test_unparse.DirectoryTestCase leaks references
Nikhil Patel added the comment: I'd like to respectfully disagree with the suggestions/conclusions mentioned here. I'll explain my reasoning and conclusions below. First the short version - I'm fairly confident the leak actually has to do with: https://github.com/python/cpython/blob/master/Lib/test/test_tools/test_unparse.py#L282 my approach: It was initially implied that we can begin to pinpoint the leak from within the test_files() method in test_tools.test_unparse.DirectoryTestCase. I ran the tests using the command: python_d -m test -R 3:3 test_tools.test_unparse -m test_files I had test_files() print the files selected in line 282 (and limited sample size to 1). Result: (note: i shortened printed pathnames manually after the fact, as it printed the absolute paths) python_d -m test -R 3:3 test_tools.test_unparse -m test_files Run tests sequentially 0:00:00 [1/1] test_tools.test_unparse Testing cpython\Lib\test\test_spwd.py beginning 6 repetitions 123456 Testing cpython\Lib\copy.py .Testing cpython\Lib\test\test_isinstance.py .Testing cpython\Lib\test\test_bytes.py .Testing cpython\Lib\test\test_csv.py .Testing cpython\Lib\test\test_dynamic.py .Testing cpython\Lib\test\test_xml_etree.py . test_tools.test_unparse leaked [3, 0, 13] references, sum=16 test_tools.test_unparse leaked [6, 2, 4] memory blocks, sum=12 test_tools.test_unparse failed 1 test failed: test_tools.test_unparse Total duration: 4 sec Tests result: FAILURE Then I made a slight modification: I replaced random.sample(names,1) on line 282 with a list containing the absolute paths to each of those files it tested in the run I described above. That means each of those files would be loaded, compiled and their tests run 6 times. Result: python_d -m test -R 3:3 test_tools.test_unparse -m test_files Run tests sequentially 0:00:00 [1/1] test_tools.test_unparse beginning 6 repetitions 123456 .. 1 test OK. Total duration: 24 sec Tests result: SUCCESS Conclusion: If the same source files are being read, compiled, and their tests run - with different results - then I do not believe the leak can be associated with the self.checkRoundTrip() method or the compile() method I don't have an in-depth explanation why this is the case. But removing the call to random.sample() fixes the issue, I am reasonably sure of it. I presume to say this because I commented out lines 280-282 and instead I made it instead iterate through subsets of size 50 using slicing (so names[:50] etc) in line 284. I went through the entire set of files, 50 at a time. All ran successfully. -- nosy: +npatel ___ Python tracker <http://bugs.python.org/issue30542> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32152] Add pid to .cover filename in lib/trace.py
New submission from Nikhil Hegde : Adding pid to filenames will avoid file write error when multiple processes (specifically, multiple tests) are writing to the same .cover file -- components: Library (Lib) messages: 307110 nosy: nikhilh priority: normal severity: normal status: open title: Add pid to .cover filename in lib/trace.py type: enhancement versions: Python 3.4 ___ Python tracker <https://bugs.python.org/issue32152> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32152] Add pid to .cover filename in lib/trace.py
Nikhil Hegde added the comment: In the trace_generic.py file that I've attached, the changes are on line 331 -- Added file: https://bugs.python.org/file47300/trace_generic.py ___ Python tracker <https://bugs.python.org/issue32152> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32152] Add pid to .cover filename in lib/trace.py
Nikhil Hegde added the comment: This is also necessary in a case where two tests (say, a and b) are running in parallel. Both tests access the same fileX.py The coverage for fileX.py will not be accurate to reflect the usage by tests a and b -- versions: +Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue32152> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32152] Add pid to .cover filename in lib/trace.py
Nikhil Hegde added the comment: Any ETA I can get on this? -- ___ Python tracker <https://bugs.python.org/issue32152> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25237] Add doc for tkinter commondialog.Dialog and subclasses
Nikhil Patel added the comment: PR to add documentation still up-to-date and all checks successful just pending review -- assignee: -> docs@python components: +Documentation nosy: +docs@python ___ Python tracker <https://bugs.python.org/issue25237> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14776] Add SystemTap static markers
Changes by Nikhil Benesch : -- nosy: +benesch ___ Python tracker <http://bugs.python.org/issue14776> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13405] Add DTrace probes
Changes by Nikhil Benesch : -- nosy: +benesch ___ Python tracker <http://bugs.python.org/issue13405> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21590] Systemtap and DTrace support
Nikhil Benesch added the comment: Since it looks like development on this has stalled, I took the liberty of compiling all prior patches https://github.com/benesch/python-dtrace-tracker and am actively working on merging them into one superpatch. I am neither a Python nor a DTrace expert, so I'm happy to step aside should one of you more experienced folks have something ready. A few thoughts so far: * SPARC support? Can we drop this? It seems to add a bunch of intrusive inlined NOPs—that I'm not sure are even necessary. * @jcea, is this the original DTrace patch? https://github.com/benesch/python-dtrace-tracker/blob/master/dtrace-solaris-oracle-24.patch I'm trying to determine where those NOPs came from. Cheers! -- nosy: +benesch ___ Python tracker <http://bugs.python.org/issue21590> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
