[issue231064] sys.path not set correctly in embedded python interpreter.

Change by admin : -- github: None -> 33847 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue221327] threads within an embedded python interpreter

Change by admin : -- github: None -> 33445 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue221327] threads within an embedded python interpreter

Change by admin : -- github: None -> 33445 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46853] Python interpreter can get code from memory, it is not secure.

Brett Cannon added the comment: This is by design and thus not a security hole or bug. Also, for any future security issues, please disclose them responsibly by following the instructions at https://www.python.org/dev/security/ . -- nosy: +brett.cannon resolution: -> not a bug

[issue46853] Python interpreter can get code from memory, it is not secure.

New submission from i5-7200u : Hi, Python Interpreter have a big security bug/error. My friend and l am. We can give virus code to Python Interpreter. we were looking for run a binary application from memory (byte array) Later we find python, but we got it is security bug/error example from

[issue46297] Python interpreter crashes on bootup with multiple PythonPaths set in registry

Change by Steve Dower : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue46297] Python interpreter crashes on bootup with multiple PythonPaths set in registry

Steve Dower added the comment: Thanks for the report and the PR! -- assignee: -> steve.dower ___ Python tracker ___ ___

[issue46297] Python interpreter crashes on bootup with multiple PythonPaths set in registry

Steve Dower added the comment: New changeset c9dc1f491e8edb0bc433cde73190a3015d226891 by Daniel in branch 'main': bpo-46297: Fix interpreter crash on startup with multiple PythonPaths set in registry (GH-30466)

[issue46297] Python interpreter crashes on bootup with multiple PythonPaths set in registry

Change by Eryk Sun : -- type: behavior -> crash ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46297] Python interpreter crashes on bootup with multiple PythonPaths set in registry

Change by Eryk Sun : -- components: +Windows nosy: +paul.moore, tim.golden, zach.ware type: crash -> behavior ___ Python tracker ___

[issue46297] Python interpreter crashes on bootup with multiple PythonPaths set in registry

Change by Ned Deily : -- nosy: +steve.dower ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46297] Python interpreter crashes on bootup with multiple PythonPaths set in registry

Change by Derzsi Dániel : -- keywords: +patch pull_requests: +28669 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30466 ___ Python tracker ___

[issue46297] Python interpreter crashes on bootup with multiple PythonPaths set in registry

: darktohka priority: normal severity: normal status: open title: Python interpreter crashes on bootup with multiple PythonPaths set in registry type: crash versions: Python 3.11 ___ Python tracker <https://bug

[issue45719] SubProcess stdin.flush freezes when running python interpreter

Eryk Sun added the comment: Interactive mode isn't automatically enabled when stdin isn't a tty, so the interpreter tries to read all of stdin, until the result is empty (i.e. EOF). You can force interactive mode with the -i command-line option. The example would also benefit from passing

[issue45719] SubProcess stdin.flush freezes when running python interpreter

files: example.py messages: 405761 nosy: djp1012878 priority: normal severity: normal status: open title: SubProcess stdin.flush freezes when running python interpreter type: behavior versions: Python 3.10 Added file: https://bugs.python.org/file50425/example.py ___ P

[issue40522] [subinterpreters] Get the current Python interpreter state from Thread Local Storage (autoTSSkey)

Change by h-vetinari : -- nosy: +h-vetinari ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43599] Setting long domain of locale.dgettext() crashes Python interpreter

Serhiy Storchaka added the comment: __dcigettext() contains: domainname_len = strlen (domainname); xdomainname = (char *) alloca (strlen (categoryname) + domainname_len + 5); It tries to allocate a buffer on stack, and for domain name causes stack

[issue43599] Setting long domain of locale.dgettext() crashes Python interpreter

Christian Heimes added the comment: The crash occurs inside glibc's dgettext() implementation. Its man page does not list any limitation for domain or msgid length. This looks like a bug in glibc. #0 0x77c57a8f in __dcigettext () from /lib64/libc.so.6 #1 0x0058a235 in

[issue43599] Setting long domain of locale.dgettext() crashes Python interpreter

Xinmeng Xia added the comment: Attached testing results of gdb and valgrind. (No error is reported for locale.dgettext('abs'*10,'')) $gdb ./python (gdb) run >>> locale.dgettext('abs'*1000,'') Program received signal SIGSEGV, Segmentation fault. __dcigettext (

[issue43663] Python interpreter works abnormally after interrupting logging.config.fileConfig()

New submission from Xinmeng Xia : Python interpreter cannot work well and report errors after interrupting logging.config.fileConfig() Reproduce step: 1. type python3 in console 2. type import logging.config; logging.config.fileConfig({2,2,'sdf'},'') 3. ctrl C 4. type 1/0

[issue43599] Setting long domain of locale.dgettext() crashes Python interpreter

New submission from Xinmeng Xia : Setting the first argument of locale.dgettext() long string, Python interpreter crashes. == Python 3.10.0a6 (default, Mar 19 2021, 11:45:56) [GCC 7.5.0] on linux Type "help", "copyr

[issue40522] [subinterpreters] Get the current Python interpreter state from Thread Local Storage (autoTSSkey)

Change by Dong-hee Na : -- pull_requests: +23375 pull_request: https://github.com/python/cpython/pull/24597 ___ Python tracker ___

[issue40522] [subinterpreters] Get the current Python interpreter state from Thread Local Storage (autoTSSkey)

Change by Dong-hee Na : -- pull_requests: +23374 pull_request: https://github.com/python/cpython/pull/24596 ___ Python tracker ___

[issue40522] [subinterpreters] Get the current Python interpreter state from Thread Local Storage (autoTSSkey)

STINNER Victor added the comment: New changeset 62078101ea1be5d2fc472a3f0d9d135e0bd5cd38 by Victor Stinner in branch 'master': bpo-40522: Replace PyThreadState_GET() with PyThreadState_Get() (GH-24575) https://github.com/python/cpython/commit/62078101ea1be5d2fc472a3f0d9d135e0bd5cd38

[issue40522] [subinterpreters] Get the current Python interpreter state from Thread Local Storage (autoTSSkey)

Change by STINNER Victor : -- pull_requests: +23354 pull_request: https://github.com/python/cpython/pull/24575 ___ Python tracker ___

[issue43188] multiple operations of dict causes core dump of Python interpreter.

Terry J. Reedy added the comment: Like the code in #43185, #43186, #43187, this works better in 3.10.0a5, so I suspect it is another duplicate. -- nosy: +terry.reedy ___ Python tracker

[issue43188] multiple operations of dict causes core dump of Python interpreter.

Inada Naoki added the comment: Is this the crash you are reporting? ``` Exception ignored in: .Mutating.__del__ at 0x100d35af0> Traceback (most recent call last): File "/Users/methane/work/python/cpython/PC/xxx.py", line 5, in __del__ mutate(d) TypeError: 'str' object is not callable

[issue43188] multiple operations of dict causes core dump of Python interpreter.

Raymond Hettinger added the comment: I can confirm this crashes. -- nosy: +methane, rhettinger ___ Python tracker ___ ___

[issue43189] decorator function run_with_locale() crashes Python interpreter

New submission from Yang Feng : We use run_with_locale() as decorator function, then we recursively call test_float__format__locale in the following example. Python interpreter crashes. +++ from test.support import run_with_locale @run_with_locale

[issue43188] multiple operations of dict causes core dump of Python interpreter.

New submission from Yang Feng : In the following programs, we call check_reentrant_insertion("s") twice, after multiple of update and clear of dict, the Python interpreter crashes. +++ def check_reentrant_insertion(mutate): clas

[issue42717] The python interpreter crashed with "_enter_buffered_busy"

Mark Shannon added the comment: Please leave the issue open. This is a real bug. It may not be fixed right now, but that doesn't mean it won't ever be fixed. -- nosy: +Mark.Shannon ___ Python tracker

[issue42717] The python interpreter crashed with "_enter_buffered_busy"

Xinmeng Xia added the comment: It seems that this bug won't be fixed. Should this issue be closed now? -- ___ Python tracker ___

[issue40522] [subinterpreters] Get the current Python interpreter state from Thread Local Storage (autoTSSkey)

Change by hai shi : -- nosy: +shihai1991 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40522] [subinterpreters] Get the current Python interpreter state from Thread Local Storage (autoTSSkey)

Change by Dong-hee Na : -- nosy: +corona10 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40522] [subinterpreters] Get the current Python interpreter state from Thread Local Storage (autoTSSkey)

STINNER Victor added the comment: One GIL per interpreter requires to store the tstate per thread. I don't see any other option. We need to replace the global _PyRuntime atomic variable with a TLS variable. I'm trying to reduce the overhead, but it's heard to beat the performance of an

[issue42717] The python interpreter crashed with "_enter_buffered_busy"

Xinmeng Xia added the comment: Thank you for your patient reply. I see now. Hoping that some one can figure out a good idea to fix this problem. -- ___ Python tracker ___

[issue42717] The python interpreter crashed with "_enter_buffered_busy"

Steve Stagg added the comment: It's one of those ugly multithreading issues that's really hard to reason about unfortunately. In this case, it's not the size of the loop so much as you've discovered a way to make it very likely that the background thread is doing IO (and holding the IO

[issue40522] [subinterpreters] Get the current Python interpreter state from Thread Local Storage (autoTSSkey)

Pablo Galindo Salgado added the comment: > An optimized Python should always be built with LTO. In MacOS is quite challenging to activate LTO, so normally optimized builds are only done with PGO. Also in Windows I am not sure is possible to use LTO. Same for many other platforms --

[issue42717] The python interpreter crashed with "_enter_buffered_busy"

Xinmeng Xia added the comment: Could we try to limit the number of thread or state or something? I mean if we set parameter of "range", for example, to 1000 or less here, the crash will no longer happen. I think the parser can not handle too heavy loop so that it crashes. --

[issue40522] [subinterpreters] Get the current Python interpreter state from Thread Local Storage (autoTSSkey)

STINNER Victor added the comment: Mark Shannon experiment using __thread: * https://mail.python.org/archives/list/python-...@python.org/thread/RPSTDB6AEMIACJFZKCKIRFTVLAJQLAS2/ * https://github.com/python/cpython/compare/master...markshannon:threadstate_in_tls He added " extern __thread

[issue42717] The python interpreter crashed with "_enter_buffered_busy"

Steve Stagg added the comment: I think the problem here is that the issue can only really be detected late on during interpreter shutdown. This makes recovery very hard to do. Plus the thread termination has left shared state in an unmanaged condition, so it's super dangerous to re-enter

[issue40522] [subinterpreters] Get the current Python interpreter state from Thread Local Storage (autoTSSkey)

STINNER Victor added the comment: PR 23976 should make _PyInterpreterState_GET() more efficient, and it prepares the code base for one GIL per interpreter (which is purpose of this issue ;-)). -- ___ Python tracker

[issue40522] [subinterpreters] Get the current Python interpreter state from Thread Local Storage (autoTSSkey)

STINNER Victor added the comment: PR 23976 stores the currrent interpreter and the current Python thread state into a Thread Local Storage (TLS) using GCC/clang __thread keyword. On x86-64 using LTO and GCC -O3, _PyThreadState_GET() and _PyInterpreterState_GET() become a single MOV.

[issue40522] [subinterpreters] Get the current Python interpreter state from Thread Local Storage (autoTSSkey)

Change by STINNER Victor : -- pull_requests: +22821 pull_request: https://github.com/python/cpython/pull/23976 ___ Python tracker ___

[issue40522] [subinterpreters] Get the current Python interpreter state from Thread Local Storage (autoTSSkey)

STINNER Victor added the comment: >_PyInterpreterState_GET(): > movrax,QWORD PTR [rip+0x22a7dd]# 0x743118 <_PyRuntime+568> > movrax,QWORD PTR [rax+0x10] While working on bpo-39465, I wrote PR 20767 to optimize _PyInterpreterState_GET(): single instruction instead of two:

[issue40522] [subinterpreters] Get the current Python interpreter state from Thread Local Storage (autoTSSkey)

STINNER Victor added the comment: There are many ways to get the current interpreter (interp) and the current Python thread state (tstate). Public C API, opaque function call: * PyInterpreterState_Get() (new in Python 3.9) * PyThreadState_Get() Internal C API, static inline functions: *

[issue42717] The python interpreter crashed with "_enter_buffered_busy"

Xinmeng Xia added the comment: Thanks for your kind explanation! Now, I have understand the causes of this core dump. Considering it will not cause core dump in Python 2.x, I am wondering should we suggest an exception to catch it rather than "core dump"? --

[issue42717] The python interpreter crashed with "_enter_buffered_busy"

Steve Stagg added the comment: Minimal test case: import sys, threading def run(): for i in range(1000): sys.stderr.write(' =.= ') if __name__ == '__main__': threading.Thread(target=run, daemon=True).start() === I think this is expected behaviour. My knowledge

[issue42717] The python interpreter crashed with "_enter_buffered_busy"

;time.sleep(0.1)" or "thread.setDaemon(True)" or "sys.stderr.write(' =_= ')" or "for i in range(0,1000)":, the python interpreter seems to work well. -- components: Interpreter Core messages: 383582 nosy: xxm priority: normal severity: normal stat

[issue42652] recursive in finally clause cause Python interpreter crash.

Change by Ronald Oussoren : -- resolution: -> fixed stage: -> resolved status: open -> closed superseder: -> crash with unbounded recursion in except statement ___ Python tracker

[issue42651] Recursive traceback crashes Python Interpreter

Change by Ronald Oussoren : -- resolution: -> fixed stage: -> resolved status: open -> closed superseder: -> crash with unbounded recursion in except statement ___ Python tracker

[issue42651] Recursive traceback crashes Python Interpreter

Xinmeng Xia added the comment: Thank you very much, looking forward to the new Python version. Could you please kindly change the resolution into fixed and close this issue? -- ___ Python tracker

[issue42652] recursive in finally clause cause Python interpreter crash.

Xinmeng Xia added the comment: Thanks for fixing this, looking forward to the new version. Could you please kindly change the resolution into fixed and close this report? -- ___ Python tracker

[issue42652] recursive in finally clause cause Python interpreter crash.

Steve Stagg added the comment: This was also fixed by bpo-42500, in commit 4e7a69bdb6 === user@obsidian ~/t/f/cpython ((93a0ef76…))> git checkout 4e7a69bd^ HEAD is now at 93a0ef7647 Correct return type in Modules/_ssl.c::sslmodule_legacy (GH-23609) + make distclean + CFLAGS=-O0 + ./configure

[issue42651] Recursive traceback crashes Python Interpreter

Steve Stagg added the comment: Sorry, previous should have read "Fixes the abort" -- ___ Python tracker ___ ___ Python-bugs-list

[issue42651] Recursive traceback crashes Python Interpreter

Steve Stagg added the comment: Confirmed that bpo-42500 fixes this traceback, in commit 4e7a69bdb6 Parent commit: user@obsidian ~/t/f/cpython (master)> git checkout 93a0ef7 Note: switching to '93a0ef7'. HEAD is now at 93a0ef7647 Correct return type in Modules/_ssl.c::sslmodule_legacy

[issue42651] Recursive traceback crashes Python Interpreter

Xinmeng Xia added the comment: In issue#36272, they discuss a bug in logging module. They show an example which is similar as this one. So I think I think there might be a similar bug in traceback module. -- ___ Python tracker

[issue42652] recursive in finally clause cause Python interpreter crash.

Xinmeng Xia added the comment: In issue #42500, crashes is resulted by recursion and try-except. Program like following will crash the interpreter. = def foo(): try: 1/0 except: pass foo() foo() = However with traceback module,

[issue42652] recursive in finally clause cause Python interpreter crash.

Ronald Oussoren added the comment: This might be related to #42500 -- nosy: +ronaldoussoren ___ Python tracker ___ ___

[issue42651] Recursive traceback crashes Python Interpreter

Ronald Oussoren added the comment: This might be related to #42500 -- nosy: +ronaldoussoren ___ Python tracker ___ ___

[issue42651] Recursive traceback crashes Python Interpreter

Change by Xinmeng Xia : -- title: Title: Recursive traceback crashes Python Interpreter -> Recursive traceback crashes Python Interpreter ___ Python tracker <https://bugs.python.org/issu

[issue42652] recursive in finally clause cause Python interpreter crash.

myerror/test1.py", line 10 in foo ... File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 10 in foo File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 10 in foo ... Aborted (core dumped) --

[issue42651] Title: Recursive traceback crashes Python Interpreter

error/test1.py", line 5 in foo File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5 in foo ... Aborted (core dumped) -- components: Interpreter Core messages: 383118 nosy: xxm priority: normal severity: normal status: open title: Title: Recursive traceback

[issue40522] [subinterpreters] Get the current Python interpreter state from Thread Local Storage (autoTSSkey)

Change by Sebastian Berg : -- nosy: +seberg ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40522] [subinterpreters] Get the current Python interpreter state from Thread Local Storage (autoTSSkey)

STINNER Victor added the comment: See also bpo-15751: "Make the PyGILState API compatible with subinterpreters". -- ___ Python tracker ___

[issue41538] Allow customizing python interpreter in venv.EnvBuilder

Change by Albert Cervin : -- keywords: +patch pull_requests: +20981 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21854 ___ Python tracker ___

[issue41538] Allow customizing python interpreter in venv.EnvBuilder

Change by Karthikeyan Singaravelan : -- nosy: +vinay.sajip versions: -Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker ___

[issue41538] Allow customizing python interpreter in venv.EnvBuilder

constructor for specifying which python interpreter to use, much like the -p flag in virtualenv. -- components: Library (Lib) messages: 375293 nosy: abbec priority: normal severity: normal status: open title: Allow customizing python interpreter in venv.EnvBuilder type: enhancement versions

[issue34821] Crash after run Python interpreter from removed directory

STINNER Victor added the comment: I understood that the bug was fixed in Python 3.5. Python 3.4 and older are no longer supported, I close the issue. -- nosy: +vstinner resolution: -> fixed stage: -> resolved status: open -> closed ___ Python

[issue40522] [subinterpreters] Get the current Python interpreter state from Thread Local Storage (autoTSSkey)

Change by STINNER Victor : -- components: +Subinterpreters -Interpreter Core title: Subinterpreters: get the current Python interpreter state from Thread Local Storage (autoTSSkey) -> [subinterpreters] Get the current Python interpreter state from Thread Local Storage (autoTSS

[issue40522] Subinterpreters: get the current Python interpreter state from Thread Local Storage (autoTSSkey)

STINNER Victor added the comment: New changeset e838a9324c1719bb917ca81ede8d766b5cb551f4 by Victor Stinner in branch 'master': bpo-40522: _PyThreadState_Swap() sets autoTSSkey (GH-19939) https://github.com/python/cpython/commit/e838a9324c1719bb917ca81ede8d766b5cb551f4 --

[issue40522] Subinterpreters: get the current Python interpreter state from Thread Local Storage (autoTSSkey)

Change by STINNER Victor : -- keywords: +patch pull_requests: +19254 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19939 ___ Python tracker ___

[issue40522] Subinterpreters: get the current Python interpreter state from Thread Local Storage (autoTSSkey)

status: open title: Subinterpreters: get the current Python interpreter state from Thread Local Storage (autoTSSkey) versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue40

[issue39581] Python Interpreter Doesn't Work Well In Thread Class

Change by SilentGhost : -- nosy: +mark.dickinson resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___

[issue39581] Python Interpreter Doesn't Work Well In Thread Class

SilentGhost added the comment: SyntaxError is produced when there is a syntax problem in the code to be executed, this code is fine from the syntax perspective, so this particular error would not be raised. It is also perfectly fine to have a function call where you have it, the only thing

[issue39581] Python Interpreter Doesn't Work Well In Thread Class

Mark Dickinson added the comment: There's no other reasonable way for Python to work here. It *is* an error to pass something that's not a callable as a thread "target", but it's a coding error that can only be detected at runtime, not a syntax error that can be detected statically before

[issue39581] Python Interpreter Doesn't Work Well In Thread Class

ws messages: 361622 nosy: paul.moore, steve.dower, tim.golden, zach.ware, 임수진학부생 priority: normal severity: normal status: open title: Python Interpreter Doesn't Work Well In Thread Class type: behavior versions: Python 3.7 ___ Python tracker

Re: Using exec with embedded python interpreter 3.7

@MRAB, I'm building a notepad++ plugin which can execute the written code and if one writes help(os) it gets executed via exec(editor.getText()) and output redirected to the plugin console window. Sorry to you as well as I have also replied to you directly. Thank you --

Re: Using exec with embedded python interpreter 3.7

Just saw, that I replied to you directly instead to python list, sorry. That did it, changed encoding from function to property and now I'm able to call help(object) Thank you. -- https://mail.python.org/mailman/listinfo/python-list

Re: Using exec with embedded python interpreter 3.7

On 2019-08-31 13:16, Eko palypse wrote: I've already sent this through mail yesterday but it doesn't appear here, maybe because of the help word in the content. Please execute in case it appears a second time. Hello, I'm creating a notepad++ plugin which hosts an embedded python interpreter

Re: Using exec with embedded python interpreter 3.7

Eko palypse wrote: > I've already sent this through mail yesterday but it doesn't appear here, > maybe because of the help word in the content. Please execute in case it > appears a second time. > > > Hello, > I'm creating a notepad++ plugin which hosts an embedded python i

Using exec with embedded python interpreter 3.7

I've already sent this through mail yesterday but it doesn't appear here, maybe because of the help word in the content. Please execute in case it appears a second time. Hello, I'm creating a notepad++ plugin which hosts an embedded python interpreter by using cffi to build the dll. So far so

Using exec with embedded python interpreter 3.7

Hello, I'm creating a notepad++ plugin which hosts an embedded python interpreter by using cffi to build the dll. So far so good. One obstacle I've found is that I'm not able to use exec(help(object)) in order to get the wanted info from the object. The error I get is: Traceback (most recent

[issue21563] Segv during call to builtin_execfile in application embedding Python interpreter.

STINNER Victor added the comment: Python 2.7 is close to it's end of life, Python 3 doesn't have execfile(), and this issue has no activity since 2014. I close the issue. -- nosy: +vstinner resolution: -> out of date stage: -> resolved status: open -> closed

[issue35988] Python interpreter segfault

Hinko Kocevar added the comment: Thank you for the valuable information about the OOM beast.. -- ___ Python tracker ___ ___

[issue35988] Python interpreter segfault

Josh Rosenberg added the comment: "your application is using more memory than what is available in the system." Well, it alone may not be using more memory, but the cumulative usage on the system is "too high" by whatever metric the OOM killer is using (IIRC the default rule is that actual

[issue35706] Make it easier to use a venv with an embedded Python interpreter

Steve Dower added the comment: That's not a "see also" - it's just a duplicate :) I'll close this one as the other one has been around longer. -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Make pyvenv style virtual environments easier to

[issue35706] Make it easier to use a venv with an embedded Python interpreter

STINNER Victor added the comment: PEP 432 will allow to give with fine control on parameters used to initialize Python. Sadly, I failed to agree with Nick Coghlan and Eric Snow on the API. The current implementation (_PyCoreConfig and _PyMainInterpreterConfig) has some flaw (don't separate

[issue35706] Make it easier to use a venv with an embedded Python interpreter

STINNER Victor added the comment: See also bpo-22213. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35988] Python interpreter segfault

Hinko Kocevar added the comment: Using python3.6 now. I've also used the 'handle SIGPIPE nostop noprint' to skip SIGPIPE. Now the interpreter is killed instead: INF 2019-02-13 15:42:19,131 web:2162 log_request - 200 GET /NPM.html (10.0.6.209) 1.10ms [Thread 0x7fffe76eb700 (LWP 8411)

[issue35988] Python interpreter segfault

STINNER Victor added the comment: > [26194250.314042] Out of memory: Kill process 8399 (python3.6) score 574 or > sacrifice child That's not a bug in Python: your application is using more memory than what is available in the system. -- ___

[issue35988] Python interpreter segfault

Hinko Kocevar added the comment: > Are you able to reproduce the crash on Python 3.6 or 3.7? I'm running it under python3.6 as we speak. -- ___ Python tracker ___

[issue35988] Python interpreter segfault

STINNER Victor added the comment: > Every now and then the python3.5 crashes, seg faults. Sorry but Python 3.5 no longer accepts bugfixes and has known bugs. http://devguide.python.org/#status-of-python-branches It's time to upgrade your Python! Are you able to reproduce the crash on Python

[issue35988] Python interpreter segfault

STINNER Victor added the comment: You can enable faulthandler to get a traceback of your Python theads when a crash occurs: https://pythondev.readthedocs.io/debug_tools.html#get-a-traceback-on-a-crash -- ___ Python tracker

[issue35988] Python interpreter segfault

STINNER Victor added the comment: > Program received signal SIGPIPE, Broken pipe. SIGPIPE is not a bug, it's a deliberate signal to notice something to your application. You have to ignore SIGPIPE in gdb: (gdb) handle SIGPIPE nostop noprint SignalStop Print Pass to program

[issue35988] Python interpreter segfault

/libpython3.5m.so.1.0 #35 0x00400a29 in main () (gdb) -- components: asyncio messages: 335447 nosy: asvetlov, hinxx, yselivanov priority: normal severity: normal status: open title: Python interpreter segfault type: crash versions: Python 3.5

[issue35706] Make it easier to use a venv with an embedded Python interpreter

PyScripter added the comment: This issue is related (duplicate) to https://bugs.python.org/issue22213. It appears that there is a workaround but only for Linux using Py_SetProgramName. I wish that there was some similar way for Windows. -- nosy: +ncoghlan, pitrou

[issue35706] Make it easier to use a venv with an embedded Python interpreter

Steve Dower added the comment: > The idea is that python, in the embedding application, should work as in the > python executable. I disagree that this is the idea. Python in the embedding application should work as in the embedding application, not the standalone one. The embedding

[issue35706] Make it easier to use a venv with an embedded Python interpreter

PyScripter added the comment: "Personally, I am 100% against letting an embedded runtime automatically pick up any settings from the environment. You don't know where they came from." Why is that? When the embedding application is using Py_SetPythonHome there is clear intent to use a

[issue35706] Make it easier to use a venv with an embedded Python interpreter

Steve Dower added the comment: Py_Initialize() is not supposed to set it up. If you are embedding Python, you have to be responsible for configuring the paths that it uses - pyvenv.cfg is configuration for Python interactive, not the shared lib (using Windows terminology, it's configuration

  1   2   3   4   5   6   7   8   >