[issue30104] Float rounding errors on AMD64 FreeBSD CURRENT Debug 3.x buildbot
Changes by Ed Maste <carpedd...@gmail.com>: -- nosy: +emaste ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30104> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24520] Stop using deprecated floating-point environment functions on FreeBSD
Changes by Ed Maste carpedd...@gmail.com: -- nosy: +emaste ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24520 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13501] Make libedit support more generic; port readline / libedit to FreeBSD
Ed Maste added the comment: I believe the 0-based vs 1-based history is only one of a few different inconsistencies between libedit and readline. Workarounds will be necessary until a fixed libedit is deployed on all operating systems / distros of interest, but yes I agree that eventually they should not be needed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13501 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13501] Make libedit support more generic; port readline / libedit to FreeBSD
Ed Maste added the comment: Actually, in msg245395 I should claim the issue is with libedit / GNU readline compatibility and/or the workarounds in Python's readline module, not that it's specifically Issue24388. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13501 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13501] Make libedit support more generic; port readline / libedit to FreeBSD
Ed Maste added the comment: It looks like rust developers hit the issue in Issue24388 with lldb on Ubuntu 15.04 as well: https://github.com/rust-lang/rust/issues/26297 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13501 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24388] Python readline module crashes in history_get on FreeBSD with libedit
Ed Maste added the comment: Presumably the #ifdefs ought to just be deleted though, relying on the runtime detection of libedit compatibility issues on any platform. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24388 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24388] Python readline module crashes in history_get on FreeBSD with libedit
New submission from Ed Maste: I encountered a segfault in Python's call_readline from LLDB on FreeBSD, with libedit. There is a fix for this issue already in readline.c, but under #ifdef __APPLE__ Backtrace: (lldb) target create /data/emaste/src/llvm/build/bin/lldb --core lldb-3.7.0.core Core file '/tank/emaste/projects/lldb-talk/demo/lldb-3.7.0.core' (x86_64) was loaded. (lldb) bt * thread #1: tid = 0, 0x000809706dcd readline.so`call_readline(sys_stdin=0x0008055d9d10, sys_stdout=0x0008055d9e40, prompt=0x000806eb7854) + 397 at readline.c:1132, name = 'lldb-3.7.0', stop reason = signal SIGSEGV * frame #0: 0x000809706dcd readline.so`call_readline(sys_stdin=0x0008055d9d10, sys_stdout=0x0008055d9e40, prompt=0x000806eb7854) + 397 at readline.c:1132 frame #1: 0x000805c48f1f libpython2.7.so.1`PyOS_Readline(sys_stdin=0x0008055d9d10, sys_stdout=0x0008055d9e40, prompt=0x000806eb7854) + 383 at myreadline.c:207 frame #2: 0x000805d7f94f libpython2.7.so.1`builtin_raw_input(self=0x, args=0x00080bec1df0) + 639 at bltinmodule.c:2060 frame #3: 0x000805cce5c6 libpython2.7.so.1`PyCFunction_Call(func=0x0008007b78d0, arg=0x00080bec1df0, kw=0x) + 166 at methodobject.c:81 frame #4: 0x000805d992aa libpython2.7.so.1`call_function(pp_stack=0x7fffbcd0, oparg=1) + 1754 at ceval.c:4033 frame #5: 0x000805d93538 libpython2.7.so.1`PyEval_EvalFrameEx(f=0x000806ecfdf0, throwflag=0) + 51160 at ceval.c:2679 frame #6: 0x000805d86c54 libpython2.7.so.1`PyEval_EvalCodeEx(co=0x000805a6af60, globals=0x000806f9a580, locals=0x, args=0x00080a06c670, argcount=2, kws=0x00080a06c680, kwcount=0, defs=0x000805aaeda8, defcount=1, closure=0x) + 5284 at ceval.c:3265 frame #7: 0x000805d9c2b6 libpython2.7.so.1`fast_function(func=0x000806f7da38, pp_stack=0x7fffc520, n=2, na=2, nk=0) + 822 at ceval.c:4129 frame #8: 0x000805d994c8 libpython2.7.so.1`call_function(pp_stack=0x7fffc520, oparg=1) + 2296 at ceval.c:4054 frame #9: 0x000805d93538 libpython2.7.so.1`PyEval_EvalFrameEx(f=0x00080a06c4b0, throwflag=0) + 51160 at ceval.c:2679 frame #10: 0x000805d86c54 libpython2.7.so.1`PyEval_EvalCodeEx(co=0x000805a5ebf0, globals=0x000806f9a580, locals=0x, args=0x00080a06c3e0, argcount=2, kws=0x00080a06c3f0, kwcount=0, defs=0x000805aaecc8, defcount=1, closure=0x) + 5284 at ceval.c:3265 frame #11: 0x000805d9c2b6 libpython2.7.so.1`fast_function(func=0x000806f7d8e8, pp_stack=0x7fffcd70, n=2, na=2, nk=0) + 822 at ceval.c:4129 frame #12: 0x000805d994c8 libpython2.7.so.1`call_function(pp_stack=0x7fffcd70, oparg=1) + 2296 at ceval.c:4054 frame #13: 0x000805d93538 libpython2.7.so.1`PyEval_EvalFrameEx(f=0x00080a06c230, throwflag=0) + 51160 at ceval.c:2679 frame #14: 0x000805d86c54 libpython2.7.so.1`PyEval_EvalCodeEx(co=0x000805a869e0, globals=0x000806f9a580, locals=0x, args=0x00080a06b9f8, argcount=0, kws=0x00080a06b9f8, kwcount=2, defs=0x0008009af688, defcount=3, closure=0x) + 5284 at ceval.c:3265 frame #15: 0x000805d9c2b6 libpython2.7.so.1`fast_function(func=0x000806f7d300, pp_stack=0x7fffd5c0, n=4, na=0, nk=2) + 822 at ceval.c:4129 frame #16: 0x000805d994c8 libpython2.7.so.1`call_function(pp_stack=0x7fffd5c0, oparg=512) + 2296 at ceval.c:4054 frame #17: 0x000805d93538 libpython2.7.so.1`PyEval_EvalFrameEx(f=0x00080a06b830, throwflag=0) + 51160 at ceval.c:2679 frame #18: 0x000805d9c16a libpython2.7.so.1`fast_function(func=0x000806f9d300, pp_stack=0x7fffdbd0, n=1, na=1, nk=0) + 490 at ceval.c:4119 frame #19: 0x000805d994c8 libpython2.7.so.1`call_function(pp_stack=0x7fffdbd0, oparg=1) + 2296 at ceval.c:4054 frame #20: 0x000805d93538 libpython2.7.so.1`PyEval_EvalFrameEx(f=0x00080098c9c0, throwflag=0) + 51160 at ceval.c:2679 frame #21: 0x000805d86c54 libpython2.7.so.1`PyEval_EvalCodeEx(co=0x0008008ffa90, globals=0x0008007d8580, locals=0x0008007d8580, args=0x, argcount=0, kws=0x, kwcount=0, defs=0x, defcount=0, closure=0x) + 5284 at ceval.c:3265 frame #22: 0x000805d857a5 libpython2.7.so.1`PyEval_EvalCode(co=0x0008008ffa90, globals=0x0008007d8580, locals=0x0008007d8580) + 85 at ceval.c:667 frame #23: 0x000805dd4a15 libpython2.7.so.1`run_mod(mod=0x00080a14f128, filename=0x000805e22022, globals=0x0008007d8580, locals=0x0008007d8580, flags=0x, arena=0x00080a027800) + 101 at pythonrun.c:1371 frame #24: 0x000805dd50a4 libpython2.7.so.1`PyRun_StringFlags(str
[issue13501] Make libedit support more generic; port readline / libedit to FreeBSD
Ed Maste added the comment: Note that the patch in Issue24388 is more a proof of concept. I'm not sure it's the right fix. LLDB is a bit of a special case: LLDB links against libedit, but the Python libedit module is built as if readline is in use. It turns out this magically works out, presumably due to the runtime workaround detection. As far as I know this issue would affect Linux as well, but perhaps the version of libedit on common Linux distributions is one with the 0-based vs 1-based history fix? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13501 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13501] Make libedit support more generic; port readline / libedit to FreeBSD
Ed Maste added the comment: This issue causes the LLDB debugger to crash on FreeBSD (it uses Python as its embedded script interpreter). What needs to be done to make some progress on this issue? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13501 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23458] [2.7] random: make the file descriptor non-inheritable (on POSIX)
Changes by Ed Maste carpedd...@gmail.com: -- nosy: +Ed.Maste ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23458 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23458] [2.7] random: make the file descriptor non-inheritable (on POSIX)
Ed Maste added the comment: For reference, this fd leak was causing one of LLDB's tests to fail. It is now marked XFAIL pending a resolution of this issue: http://llvm.org/viewvc/llvm-project?view=revisionrevision=229704 Linux is also affected, the Linux LLDB tests were previously running on an earlier Python version which did not demonstrate this problem. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23458 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS)
Changes by Ed Maste carpedd...@gmail.com: -- nosy: +Ed.Maste ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15745 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
