[issue20766] reference leaks in pdb
Jack Liu added the comment: Good to know the fix will be included Python official builds. Thanks. -- ___ Python tracker <http://bugs.python.org/issue20766> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28520] Failed to install Python 3.3.5 on OSX 10.11.6
New submission from Jack Liu: For some reason. I need to install Python 3.3.5 (64-bit) on OSX 10.11.6. I got installer from http://www.python.org/ftp/python/3.3.5/python-3.3.5-macosx10.6.dmg, failed to install Python 3.3.5 on OSX 10.11.6. See error in attached screenshot. I know it's able to install Python 3.3.5 (64-bit) through pyenv. But I want to know why it's failed to install Python 3.3.5 on OSX 10.11.6 through python official installer. How can I make the python official installer work. -- components: Installation files: large.png messages: 279309 nosy: Jack Liu priority: normal severity: normal status: open title: Failed to install Python 3.3.5 on OSX 10.11.6 versions: Python 3.3 Added file: http://bugs.python.org/file45204/large.png ___ Python tracker <http://bugs.python.org/issue28520> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20766] reference leaks in pdb
Jack Liu added the comment: Now, I have to set nosigint to True to fix the reference leaks issue for my app. -- ___ Python tracker <http://bugs.python.org/issue20766> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20766] reference leaks in pdb
Jack Liu added the comment: Will the issue be fixed in Python formal build? I still meet the same issue with Python 3.5.1. It cost me a bit time to track down this issue. I'm using pdb to debug a Python script, there are global variables in the script. Duo the leak of sigint_handler, calling gc.collect() doesn't release the global variables until calling PyOS_FiniInterrupts(). -- nosy: +Jack Liu, draghuram, gregory.p.smith, isandler, r.david.murray versions: +Python 3.5 ___ Python tracker <http://bugs.python.org/issue20766> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28202] Python 3.5.1 C API, the global variable is not destroyed when delete the module
Changes by Jack Liu : -- nosy: +pitrou ___ Python tracker <http://bugs.python.org/issue28202> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28202] Python 3.5.1 C API, the global variable is not destroyed when delete the module
Jack Liu added the comment: @serhiy.storchaka, The reference counts before PyDict_DelItemString are same on Python 3.3, 3.5 and 3.6. Py_REFCNT(py_module)1 Py_REFCNT(py_dict)4 -- ___ Python tracker <http://bugs.python.org/issue28202> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28202] Python 3.5.1 C API, the global variable is not destroyed when delete the module
Jack Liu added the comment: Looks to me, there is NO reference cycle on the Simple object in the python test code. Why needs to call PyGC_Collect() here? -- ___ Python tracker <http://bugs.python.org/issue28202> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28202] Python 3.5.1 C API, the global variable is not destroyed when delete the module
Jack Liu added the comment: The problem is resolved if call PyGC_Collect() after PyDict_DelItemString(). Is it expected to call PyGC_Collect() here? -- ___ Python tracker <http://bugs.python.org/issue28202> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28202] Python 3.5.1 C API, the global variable is not destroyed when delete the module
Jack Liu added the comment: I know there is a workaround to set the global variables to None at last in Python scripts. But my app just provide a framework for my customers to run python scripts. That means the workaround requires my customers to update their python scripts. That may make them unhappy :(. First, we need to confirm if it's a bug of Python 3.5. If it's a bug of Python 3.5, is there a workaround in my code C++ side to call Python C APIs to resolve the memory leak issue? If it's not a bug of Python 3.5, is there any mistake in my C++ code? -- ___ Python tracker <http://bugs.python.org/issue28202> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28202] Python 3.5.1 C API, the global variable is not destroyed when delete the module
Jack Liu added the comment:
I wrote the test code as below. I also attached the files in attachment.
Python
=
class Simple:
def __init__( self ):
print('Simple__init__')
def __del__( self ):
print('Simple__del__')
simple = None
def run():
global simple
simple = Simple()
if __name__ == '__main__':
run()
==
C++
=
#include "stdafx.h"
#include
#include
#include
#include
#include
#include
using namespace std;
namespace {
wstring readfile(const wchar_t *filename)
{
wifstream wifs;
wifs.open(filename);
//wifs.imbue(locale(wifs.getloc(), new codecvt_utf8()));
wstring wstr((std::istreambuf_iterator(wifs)),
std::istreambuf_iterator());
return wstr;
}
string wstrtostr(const wstring& ws)
{
std::wstring_convert> converter;
return converter.to_bytes(ws);
}
}
int main()
{
cout << "Input py file full path:" << endl;
wstring filePath;
wcin >> filePath;
//filePath = L"L:\\Dev\\PyTest\\SimpleTest.py";
string moduleName = "__main__";
string script = wstrtostr(readfile(filePath.c_str()));
if (script.empty())
{
cout << "Invalid python file path" << endl;
return 1;
}
string sfileName = wstrtostr(filePath);
// Initialize the Python Interpreter
Py_Initialize();
PyObject *py_module = PyImport_AddModule(moduleName.c_str());
PyObject *py_dict = PyModule_GetDict(py_module);
PyObject* res = nullptr;
auto arena = PyArena_New();
if (arena)
{
auto mod = PyParser_ASTFromString(script.c_str(),
sfileName.c_str(), Py_file_input, nullptr, arena);
if (mod)
{
auto co = PyAST_Compile(mod, sfileName.c_str(),
nullptr, arena);
if (co)
{
res = PyEval_EvalCode((PyObject*)(co), py_dict,
py_dict);
Py_DECREF(co);
}
}
PyArena_Free(arena);
}
if (res)
{
Py_DECREF(res);
}
// Delete the module from sys.modules
PyObject* modules = PyImport_GetModuleDict();
cout << "PyDict_DelItemString" << endl;
PyDict_DelItemString(modules, moduleName.c_str());
// May run many scripts here
// Finish the Python Interpreter
cout << "Py_Finalize" << endl;
Py_Finalize();
return 0;
}
===
The expected output in console should be:
Simple__init__
PyDict_DelItemString
Simple__del__
Py_Finalize
I tested with Python 3.2.5, 3.3.5, 3.5.1 and 3.6.0 beta.
It worked as expected with Python 3.2.5 and 3.3.5, but did not work Python
3.5.1 and 3.6.0 beta.
On Python 3.5.1 and 3.6.0 beta, the output is:
Simple__init__
PyDict_DelItemString
Py_Finalize
Simple__del__
That means the Simple object is not released at PyDict_DelItemString, it's
released at Py_Finalize.
So it it a regression bug since Python 3.5? I wish there is a solution to
resolve memory leak issue.
--
Added file: http://bugs.python.org/file44748/PyTest.zip
___
Python tracker
<http://bugs.python.org/issue28202>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28202] Python 3.5.1 C API, the global variable is not destroyed when delete the module
Jack Liu added the comment: @eric.snow, Thank you for the replay. You understood right. I run this module as __main__ module, so there is no other modules to reference this module. And as I debugged, the ref count of this module became 0 after calling PyDict_DelItemString, but global variable in this module was not released with Python 3.5.1. Is that memory leak? As I said, it worked on python 3.3. Is it a regression in python 3.5.1? Any workaround to resolve this problem? It's an urgency issue to me. -- ___ Python tracker <http://bugs.python.org/issue28202> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28202] Python 3.5.1 C API, the global variable is not destroyed when delete the module
Jack Liu added the comment:
I have a app loading python35.dll. Use python API PyImport_AddModule to run a
py file. And use PyDict_DelItemString to delete the module. There is a global
vailable in the py file. The global variable is not destroyed when calling
PyDict_DelItemString to delete the module. The global variable is destroyed
when calling Py_Finalize. It's too late. That cause the memory leak. Because
the Py_Initialize is called at the app startup, the Py_Finalize is called at
the app shutdown.
But it is ok with python33.dll, the global variable can be destroyed when
calling PyDict_DelItemString to delete the module.
How to resolve the problem? Is there a workaround? I need to use python35.dll
and wish the global variable in a module can be released automatically when
call PyDict_DelItemString to delete the module.
Here is the python test code:
class Simple:
def __init__( self ):
print('Simple__init__')
def __del__( self ):
print('Simple__del__')
simple = Simple()
--
___
Python tracker
<http://bugs.python.org/issue28202>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28202] Python 3.5.1 C API, the global variable is not destroyed when delete the module
Changes by Jack Liu : -- components: +Extension Modules -Library (Lib) title: Python 3.5.1 C API, the global available available is not destroyed when delete the module -> Python 3.5.1 C API, the global variable is not destroyed when delete the module ___ Python tracker <http://bugs.python.org/issue28202> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28202] Python 3.5.1 C API, the global available available is not destroyed when delete the module
New submission from Jack Liu:
0
down vote
favorite
I have a app loading python35.dll. Use python API PyImport_AddModule to run a
py file. And use PyDict_DelItemString to delete the module. There is a global
vailable in the py file. The global variable is not destroyed when calling
PyDict_DelItemString to delete the module. That cause the memory leak.
But it is ok with python33.dll, the global variable can be destroyed when
calling PyDict_DelItemString to delete the module.
How to resolve the problem? Is there a workaround? I need to use python35.dll
and wish the global variable in a module can be released automatically when
call PyDict_DelItemString to delete the module.
Here is the python test code:
class Simple:
def __init__( self ):
print('Simple__init__')
def __del__( self ):
print('Simple__del__')
simple = Simple()
--
components: Library (Lib)
messages: 276945
nosy: Jack Liu
priority: normal
severity: normal
status: open
title: Python 3.5.1 C API, the global available available is not destroyed when
delete the module
type: behavior
versions: Python 3.5
___
Python tracker
<http://bugs.python.org/issue28202>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
