[issue43356] PyErr_SetInterrupt should have an equivalent that takes a signal number

[Antoine Pitrou]

New submission from Antoine Pitrou :

PyErr_SetInterrupt() is useful if you want to simulate the effect of a SIGINT.
It would be helpful to provide a similar primitive for other signal numbers, 
e.g. `PyErr_SetInterruptEx(int signum)`.

--
components: C API
messages: 387877
nosy: pitrou
priority: normal
severity: normal
status: open
title: PyErr_SetInterrupt should have an equivalent that takes a signal number
type: enhancement
versions: Python 3.10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43244] Move PyArena C API to the internal C API

[hai shi]

Change by hai shi :


--
keywords: +patch
nosy: +shihai1991
nosy_count: 1.0 -> 2.0
pull_requests: +23470
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24688

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43354] xmlrpc.client: Fault.faultCode erroneously documented to be a string, should be int

[Dong-hee Na]

Change by Dong-hee Na :


--
nosy: +corona10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43284] Wrong windows build in 20H2

[Dong-hee Na]

Change by Dong-hee Na :


--
nosy: +corona10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43348] XMLRPC behaves strangely under pythonw, not under python

[Tim Magee]

Tim Magee  added the comment:

After a peep at the source I theorised that using logRequests=False when 
constructing the base class, SimpleXMLRPCServer. would see me right, and so it 
did.

When logRequests is True control ultimately passes to 
BaseHTTPRequestHandler.log_message which is a write to sys.stderr, meaning the 
code is unsuitable for running under pythonw.

This might be a special sort of https://bugs.python.org/issue38533 -- special 
because the code that offends pythonw is in the library.

Anyhow, now I know what the problem is I can work round it, and I'll leave it 
to you what to do with the ticket.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43355] __future__.annotations breaks inspect.signature()

[Eric Engestrom]

New submission from Eric Engestrom :

We have a pytest that boils down to the following:

```
#from __future__ import annotations
from inspect import Parameter, signature


def foo(x: str) -> str:
return x + x


def test_foo():
expected = (
Parameter("x", Parameter.POSITIONAL_OR_KEYWORD, annotation=str),
)

actual = tuple(signature(foo).parameters.values())

assert expected == actual
```

(execute with `pip install pytest && pytest -vv test_foo.py`)

I tried importing 3.10 annotations (so that we can get rid of quotes around the 
class containing `foo()`, which is omitted here because it isn't necessary to 
reproduce the bug), but doing so changes the output of `inspect.signature()` 
but not the output `inspect.Parameter()`, causing a mismatch between the two 
that breaks the test.

The above passes on 3.7.9, 3.8.7 & 3.9.1, and if I uncomment the first line, it 
fails on those same versions.
As can be expected, the annotations import is a no-op on 3.10.0a5 and the test 
passes either way.

I expect `inspect` might have not been correctly updated to support postponed 
annotations, but I haven't looked at the implementation (I'm not familiar with 
the CPython codebase at all) so it's just a guess.

--
components: Library (Lib)
messages: 387875
nosy: 1ace
priority: normal
severity: normal
status: open
title: __future__.annotations breaks inspect.signature()
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33515] subprocess.Popen on a Windows batch file always acts as if shell=True

[Eryk Sun]

Change by Eryk Sun :


--
stage: patch review -> 
versions: +Python 3.10, Python 3.9 -Python 2.7, Python 3.6, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19050] [Windows] fflush called on pointer to potentially closed file

[Eryk Sun]

Change by Eryk Sun :


--
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18597] On Windows sys.stdin.readline() doesn't handle Ctrl-C properly

[Eryk Sun]

Change by Eryk Sun :


--
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8036] raise ValueError for empty `path` in os.spawnv[e]

[Eryk Sun]

Eryk Sun  added the comment:

The internal spawn function in ucrt, common_spawnv(), verifies its parameters 
as follows:

_VALIDATE_RETURN(file_name   != nullptr, EINVAL, -1);
_VALIDATE_RETURN(file_name[0]!= '\0',EINVAL, -1);
_VALIDATE_RETURN(arguments   != nullptr, EINVAL, -1);
_VALIDATE_RETURN(arguments[0]!= nullptr, EINVAL, -1);
_VALIDATE_RETURN(arguments[0][0] != '\0',EINVAL, -1);

Currently os.spawnv() and os.spawnve() check for and raise ValueError for all 
of these cases except the second one, in which file_name is an empty string. 
Microsoft doesn't document this case [1]:

These functions validate their parameters. If either cmdname or argv 
is a null pointer, or if argv points to null pointer, or argv[0] is 
an empty string, the invalid parameter handler is invoked, as 
described in Parameter Validation.

In a release build, this case fails with EINVAL. In a debug build, the default 
error-reporting settings display a pop message about the invalid argument. The 
message box is easy enough to suppress. But for the sake of consistency with 
the other cases, os_spawnv_impl in Modules/posixmodule.c should raise a 
ValueError if `path` is an empty string. For example:

#ifdef HAVE_WSPAWNV
if (!path->wide[0]) {
PyErr_SetString(PyExc_ValueError,
"spawnv() arg 1 cannot be an empty string");
return NULL;
}
#endif

---
[1] 
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/spawnv-wspawnv

--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
priority: high -> normal
title: Interpreter crashes on invalid arg to spawnl on Windows -> raise 
ValueError for empty `path` in os.spawnv[e]
type: crash -> behavior
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.2, Python 
3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43354] xmlrpc.client: Fault.faultCode erroneously documented to be a string, should be int

[Paul Ganssle]

Paul Ganssle  added the comment:

The evidence you have here seems pretty compelling and this change seems 
straightforward enough. I don't see an expert listed here, but I'm happy to 
merge a docs PR fixing this.

Probably a good idea to make a PR to typeshed in parallel, in case they have 
some further insight into this.

--
nosy: +p-ganssle

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43353] Document that logging.getLevelName() can return a numeric value.

[Vinay Sajip]

Vinay Sajip  added the comment:

Sure, I'll look at a PR that mentions the other usage above the "changed in 
3.4" section.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43342] Error while using Python C API

[Piyush Patel]

Piyush Patel  added the comment:

Hi 

Thanks for your time.

Just wanted to add that earlier I used

PyImport_AddModule(""__main__").

but now I used PyImport_ImportModule(""__main__") 

resolved the issue for me regardless of installation path it worked.

Thanks 
Piyush

--
resolution:  -> works for me
stage:  -> resolved
status: pending -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43344] RotatingFileHandler breaks file type associations

[Vinay Sajip]

Vinay Sajip  added the comment:

As per the documentation at

https://docs.python.org/3/library/logging.handlers.html#logging.handlers.BaseRotatingHandler.namer

You can set the handler's "namer" attribute to a callable that returns a 
computed name for the rotated file - this can be computed as per your 
requirements. The cookbook also has an entry about this:

https://docs.python.org/3/howto/logging-cookbook.html#using-a-rotator-and-namer-to-customize-log-rotation-processing

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43349] [doc] incorrect tuning(7) manpage link

[miss-islington]

miss-islington  added the comment:


New changeset 643939a07e480ed88a6eca9793157f1c695a418e by Miss Islington (bot) 
in branch '3.8':
closes bpo-43349: Fix tuning(7) manpage hyperlink. (GH-24680)
https://github.com/python/cpython/commit/643939a07e480ed88a6eca9793157f1c695a418e


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43349] [doc] incorrect tuning(7) manpage link

[Benjamin Peterson]

Benjamin Peterson  added the comment:


New changeset f4d7d46cb48aa3a1bf3c2c7e2d7d71cbf49dea69 by Erlend Egeberg 
Aasland in branch 'master':
closes bpo-43349: Fix tuning(7) manpage hyperlink. (GH-24680)
https://github.com/python/cpython/commit/f4d7d46cb48aa3a1bf3c2c7e2d7d71cbf49dea69


--
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43349] [doc] incorrect tuning(7) manpage link

[miss-islington]

Change by miss-islington :


--
pull_requests: +23469
pull_request: https://github.com/python/cpython/pull/24685

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43349] [doc] incorrect tuning(7) manpage link

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +23468
pull_request: https://github.com/python/cpython/pull/24684

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34064] subprocess functions with shell=1 pass wrong command to win32 shell

[Eryk Sun]

Change by Eryk Sun :


--
resolution:  -> third party
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43348] XMLRPC behaves strangely under pythonw, not under python

[Tim Magee]

Tim Magee  added the comment:

Fragment more info.  First a typo in the description, at the end of the MTR 
"unexpected connection" should read "unexpected disconnection" of course 
(no-one expects the unexpected connection ho ho).

Looking at calls to socket functions, Procmon shows the client repeating the 
call to a server running in pythonw.exe. It seems as though the client is 
instigating the badness, but...

In a Wireshark capture each of the two sessions the client holds with that 
'bad' server is identical, and the difference between each of those and the 
'good' session (with the server in python.exe) is that the server under pythonw 
doesn't return a methodResponse packet, but instead begins tearing down the 
connection.  Which is what the exception message says, but it's still startling 
to see it actually happening.

I'll have a squint at the source.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33245] Unable to send CTRL_BREAK_EVENT

[Eryk Sun]

Change by Eryk Sun :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Windows: SystemError during os.kill(..., signal.CTRL_C_EVENT)

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43354] xmlrpc.client: Fault.faultCode erroneously documented to be a string, should be int

[Jürgen Gmach]

New submission from Jürgen Gmach :

I created a XMLRPC API (via Zope), which gets consumed by a C# application.

C#'s XMLRPC lib expects an `int` for the `faultCode` but I currently return a 
string, as this is the type which is currently documented in the official docs
https://docs.python.org/3/library/xmlrpc.client.html#xmlrpc.client.Fault.faultCode

This leads to a `TypeMismatch` error on the client's side.


The documentation for `faultCode` is pretty much unchanged since 2007, when 
`xmlrpc.client.rst` was first created (at least at that place) by Georg Brandl. 
The docs are most probably older, but I do not know where they were managed 
before.

I had a look at the cpython source code, and at least the tests all use ints 
for `faultCode` (both of them :-) )

eg 
https://github.com/python/cpython/blob/255f53bdb54a64b93035374ca4484ba0cc1b41e1/Lib/test/test_xmlrpc.py#L166

Having a look at the XMLRPC spec at http://xmlrpc.com/spec.md it is clearly 
shown that `faultCode` has to be an int.

Typeshed recently added type hints for xmlrpc lib, and they used string for 
`faultCode` - but I guess this is just an aftereffect from the faulty 
documentation.
https://github.com/python/typeshed/pull/3834

I suggest to both update cpython's documentation and to create a PR for 
typeshed in order to fix the type issue.

If any core dev agrees on this, I'd like to prepare the pull requests.

Thanks for taking your time to look into this!

--
assignee: docs@python
components: Documentation
messages: 387866
nosy: docs@python, jugmac00
priority: normal
severity: normal
status: open
title: xmlrpc.client: Fault.faultCode erroneously documented to be a string, 
should be int
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43350] [sqlite3] Active statements are reset twice in _pysqlite_query_execute()

[Erlend Egeberg Aasland]

Erlend Egeberg Aasland  added the comment:

Hm, I guess we could use sqlite3_stmt_busy() instead of the in_use flag.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43351] `RecursionError` during deallocation

[Andrew V. Jones]

Andrew V. Jones  added the comment:

Same logic, but this crashes:

```
def loop():
a_node = boost_python_library.get_linked_list()
temp = []
while True:
assert a_node is not None
temp.append(a_node)
prev = a_node   # <-- comment this out to make the crash go away
a_node = a_node.next
if not a_node:
break
```

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14597] Cannot unload dll in ctypes until script exits

[Eryk Sun]

Eryk Sun  added the comment:

Automatically decrementing the reference count of a shared library (e.g. via 
WinAPI FreeLibrary or POSIX dlclose) when a CDLL instance is finalized would 
require significant design changes to ensure that all ctypes pointers, scalars, 
and aggregates that reference memory in the DLL also always reference the CDLL 
instance in their _objects attribute. I don't think this feature request is 
worth the work that involves, or the risk of crashing if some case is 
overlooked in the implementation. Nothing prevents a script from implementing 
this manually on a case by case basis.

--
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43351] `RecursionError` during deallocation

[Andrew V. Jones]

Andrew V. Jones  added the comment:

Here's some representative code that triggers the issue:

```
def loop():
a_node = boost_python_library.get_linked_list()
all_elems = []
while a_node is not None:
#
# Uncomment the below to make the crash disappear
#
# all_elems.append(a_node)
#
a_node = a_node.next
```

The *really* interesting bit is that if we save what comes off the Boost.Python 
linked list into a Python-proper list (`all_elems` as above), then the crash 
goes away.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33105] os.path.isfile returns false on Windows when file path is longer than 260 characters

[Eryk Sun]

Eryk Sun  added the comment:

I'm closing this as not a bug. If the process limits DOS paths to MAX_PATH, 
then checking os.path.isfile() should not be special cased to support longer 
DOS paths because calling open() on such a path will raise FileNotFoundError. 
My suggestion in msg314126 to have stat() fall back on querying the directory 
in this case is too magical, even if it does make os.stat() more consistent 
with os.listdir() and the stat result from os.scandir().

--
resolution:  -> not a bug
stage: needs patch -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31447] proc communicate not exiting on python subprocess timeout using PIPES

[Eryk Sun]

Eryk Sun  added the comment:

I'm changing this to a documentation issue and removing the Windows component. 
The documentation doesn't make it clear that communicate() may block 
indefinitely (in both POSIX and Windows) even after the process has terminated. 
As currently implemented, this claim and the example need to be corrected. 

Depending on one's needs, the Popen() instance can be used as context manager 
to ensure that communication is finalized (e.g. in Windows, the synchronous 
reads in worker threads need to be canceled) and that the pipes are closed -- 
presuming you don't need to read more data after the timeout. If issue 43346 is 
resolved as suggested, then the following will work without blocking 
indefinitely in the second communicate() call:

proc = subprocess.Popen(...)
try:
out, err = proc.communicate(timeout=15)
except subprocess.TimeoutExpired:
with proc:
proc.kill()
out, err = proc.communicate()

--
assignee:  -> docs@python
components: +Documentation -Windows
nosy: +docs@python
stage:  -> needs patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43350] [sqlite3] Active statements are reset twice in _pysqlite_query_execute()

[Erlend Egeberg Aasland]

Erlend Egeberg Aasland  added the comment:

> There are three calls of pysqlite_statement_reset() in 
> _pysqlite_query_execute()

Yes, but only two before the cache is queried.

> So additional call of pysqlite_statement_reset() does not harm.

That's true, but removing redundant code makes it easier to read and maintain, 
IMO.

> On other hand removing it can introduce race condition.

How?

> Maybe the code could be rewritten in more explicit way and call 
> pysqlite_statement_reset() only when it is necessary

Most of _pysqlite_query_execute() could be rewritten in order to make the code 
clearer. An alternative is to clean it up part by part.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43350] [sqlite3] Active statements are reset twice in _pysqlite_query_execute()

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

There are three calls of pysqlite_statement_reset() in 
_pysqlite_query_execute(). And all three of them can be called with the same 
statement object. But repeated calls are no-ops because 
pysqlite_statement_reset() clears flag in_use and calls sqlite3_reset() only if 
it was set before. So additional call of pysqlite_statement_reset() does not 
harm. You can call it as many times as you want. On other hand removing it can 
introduce race condition.

Maybe the code could be rewritten in more explicit way and call 
pysqlite_statement_reset() only when it is necessary, but for now I don't think 
that just removing one call will make the code better.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43342] Error while using Python C API

[Eric V. Smith]

Eric V. Smith  added the comment:

You're going to get more help by posting your question elsewhere. This isn't a 
forum where we can help you debug your code: it's for reporting bugs in Python.

You might try https://discuss.python.org/c/users/, or maybe the python-list 
mailing list.

Good luck!

--
nosy: +eric.smith
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43353] Document that logging.getLevelName() can return a numeric value.

[Mariusz Felisiak]

New submission from Mariusz Felisiak :

Can we document[1] that `logging.getLevelName()` returns a numeric value when 
corresponding string is passed in (related with 
https://bugs.python.org/issue1008295). I know that we have "Changed in version 
3.4" annotation but I think it's worth mentioning in the main description.

I hope it's not a duplicate, I tried to find matching ticket. 

I can submit PR if accepted.

[1] 
https://docs.python.org/3.10/library/logging.html?highlight=getlevelname#logging.getLevelName

--
components: Library (Lib)
messages: 387856
nosy: felixxm, vinay.sajip
priority: normal
severity: normal
status: open
title: Document that logging.getLevelName() can return a numeric value.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43352] Add a Barrier object in asyncio lib

[Yves Duprat]

New submission from Yves Duprat :

Add a synchronized primitive Barrier in asyncio, in order to be consistent with 
them we have for threading.

Barrier object will have a similar design from that of threading lib.
(May be we have to think about a backport ?)


Initial discussion started here: 
https://mail.python.org/archives/list/python-id...@python.org/thread/IAFAH7PWMUDUTLXYLNSXES7VMDQ26A3W/

--
components: asyncio
messages: 387855
nosy: asvetlov, yduprat, yselivanov
priority: normal
severity: normal
status: open
title: Add a Barrier object in asyncio lib
type: enhancement
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43330] xmlrpc.Server URI query and fragment are discarded from HTTP query since py3

[Julien Castiaux]

Change by Julien Castiaux :


--
keywords: +patch
pull_requests: +23467
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24683

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11717] conflicting definition of ssize_t in pyconfig.h

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11717] conflicting definition of ssize_t in pyconfig.h

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset c994ffe69553cbb34f1cea6a4494d6e7657f41b0 by Jozef Grajciar in 
branch 'master':
bpo-11717: fix ssize_t redefinition error when targeting 32bit Windows app 
(GH-24479)
https://github.com/python/cpython/commit/c994ffe69553cbb34f1cea6a4494d6e7657f41b0


--
nosy: +pablogsal

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43271] AMD64 Windows10 3.x crash with Windows fatal exception: stack overflow

[Mark Shannon]

Mark Shannon  added the comment:

PEP 651 would prevent any crashes, although some of the tests might still fail 
with a StackOverflowException, if they weren't expecting a RecursionError.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43351] `RecursionError` during deallocation

[Andrew V. Jones]

New submission from Andrew V. Jones :

I am currently working with "porting" some code from Python 2.7.14 to Python 
3.7.5, but the process running the Python code seems to terminate in the 
following way:

```
#0  0x2ef63337 in raise () from /lib64/libc.so.6
#1  0x2ef64a28 in abort () from /lib64/libc.so.6
#2  0x2e726e18 in fatal_error (prefix=0x0, msg=0x2e8091f0 "Cannot 
recover from stack overflow.", status=-1) at Python/pylifecycle.c:2187
#3  0x2e727603 in Py_FatalError (msg=0x9bf0 ) at Python/pylifecycle.c:2197
#4  0x2e6ede2b in _Py_CheckRecursiveCall (where=) at 
Python/ceval.c:489
#5  0x2e62b61d in _PyMethodDef_RawFastCallDict (method=0x2eae2740 
, self=0x2aaabb1d4d70, args=0x0, nargs=0, 
kwargs=0x0) at Objects/call.c:464
#6  0x2e62b6a9 in _PyCFunction_FastCallDict (func=0x2aaabeaa5690, 
args=0x6, nargs=0, kwargs=0x0) at Objects/call.c:586
#7  0x2e62c56c in _PyObject_CallFunctionVa (callable=0x9bf0, 
format=, va=, is_size_t=) at 
Objects/call.c:935
#8  0x2e62cc80 in callmethod (is_size_t=, va=, format=, callable=) at Objects/call.c:1031
#9  _PyObject_CallMethodId (obj=, name=, 
format=0x0) at Objects/call.c:1100
#10 0x2e724c51 in flush_std_files () at Python/pylifecycle.c:1083
#11 0x2e72704f in fatal_error (prefix=0x0, msg=, 
status=-1) at Python/pylifecycle.c:2175
#12 0x2e727603 in Py_FatalError (msg=0x9bf0 ) at Python/pylifecycle.c:2197
#13 0x2e6ede2b in _Py_CheckRecursiveCall (where=) at 
Python/ceval.c:489
#14 0x2e62ba3d in _PyObject_FastCallDict (callable=0x2aaabeab8790, 
args=, nargs=, kwargs=0x0) at Objects/call.c:120
#15 0x2e62c2f0 in object_vacall (callable=0x2aaabeab8790, 
vargs=0x7ff54d40) at Objects/call.c:1202
#16 0x2e62c3fd in PyObject_CallFunctionObjArgs (callable=0x9bf0) at 
Objects/call.c:1267
#17 0x2e6c1bf0 in PyObject_ClearWeakRefs (object=) at 
Objects/weakrefobject.c:872
#18 0x2e4b26f6 in instance_dealloc () from 
/home/LOCAL/avj/build/vc21__90601_pyedg_improvements/vc/lib64/libboost_python37.so.1.69.0
#19 0x2e67c3e0 in subtype_dealloc (self=0x2aaabeab9e40) at 
Objects/typeobject.c:1176
#20 0x2e4ba63f in life_support_call () from 
/home/LOCAL/avj/build/vc21__90601_pyedg_improvements/vc/lib64/libboost_python37.so.1.69.0
#21 0x2e62b9c4 in _PyObject_FastCallDict (callable=0x2aaabeab87b0, 
args=, nargs=, kwargs=0x0) at Objects/call.c:125
#22 0x2e62c2f0 in object_vacall (callable=0x2aaabeab87b0, 
vargs=0x7ff54fd0) at Objects/call.c:1202
#23 0x2e62c3fd in PyObject_CallFunctionObjArgs (callable=0x9bf0) at 
Objects/call.c:1267
#24 0x2e6c1bf0 in PyObject_ClearWeakRefs (object=) at 
Objects/weakrefobject.c:872
#25 0x2e4b26f6 in instance_dealloc () from 
/home/LOCAL/avj/build/vc21__90601_pyedg_improvements/vc/lib64/libboost_python37.so.1.69.0
#26 0x2e67c3e0 in subtype_dealloc (self=0x2aaabeab9e90) at 
Objects/typeobject.c:1176
#27 0x2e4ba63f in life_support_call () from 
/home/LOCAL/avj/build/vc21__90601_pyedg_improvements/vc/lib64/libboost_python37.so.1.69.0
#28 0x2e62b9c4 in _PyObject_FastCallDict (callable=0x2aaabeab87d0, 
args=, nargs=, kwargs=0x0) at Objects/call.c:125
#29 0x2e62c2f0 in object_vacall (callable=0x2aaabeab87d0, 
vargs=0x7ff55260) at Objects/call.c:1202
#30 0x2e62c3fd in PyObject_CallFunctionObjArgs (callable=0x9bf0) at 
Objects/call.c:1267
#31 0x2e6c1bf0 in PyObject_ClearWeakRefs (object=) at 
Objects/weakrefobject.c:872
#32 0x2e4b26f6 in instance_dealloc () from 
/home/LOCAL/avj/build/vc21__90601_pyedg_improvements/vc/lib64/libboost_python37.so.1.69.0
#33 0x2e67c3e0 in subtype_dealloc (self=0x2aaabeab9ee0) at 
Objects/typeobject.c:1176
#34 0x2e4ba63f in life_support_call () from 
/home/LOCAL/avj/build/vc21__90601_pyedg_improvements/vc/lib64/libboost_python37.so.1.69.0
```

This is only the inner most 35 frames -- the actual back-trace is 7375 frames 
deep, and ends with:

```
#7358 0x2e4b26f6 in instance_dealloc () from 
/home/LOCAL/avj/build/vc21__90601_pyedg_improvements/vc/lib64/libboost_python37.so.1.69.0
#7359 0x2e67c3e0 in subtype_dealloc (self=0x2aaabeaefdf0) at 
Objects/typeobject.c:1176
#7360 0x2e6f2f46 in _PyEval_EvalFrameDefault (f=0x2aaabce48b30, 
throwflag=39920) at Python/ceval.c:1098
#7361 0x2e62a959 in function_code_fastcall (co=, 
args=0x7fffd088, nargs=1, globals=) at Objects/call.c:283
#7362 0x2e62ae44 in _PyFunction_FastCallDict (func=0x2aaabda07950, 
args=0x7fffd080, nargs=1, kwargs=0x0) at Objects/call.c:322
#7363 0x2e62bbea in _PyObject_Call_Prepend (callable=0x2aaabda07950, 
obj=0x2aaabea92590, args=0x2aaabb193050, kwargs=0x0) at Objects/call.c:908
#7364 0x2e62b9c4 in _PyObject_FastCallDict (callable=0x2aaabb253a50, 
args=, nargs=, kwargs=0x0) at Objects/call.c:125
#7365 0x2e62c677 in 

[issue43340] json.load() can raise UnicodeDecodeError, but this is not documented

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

json.loads() accepts also data encoded with UTF-16 and UTF-32.

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43350] [sqlite3] Active statements are reset twice in _pysqlite_query_execute()

[Erlend Egeberg Aasland]

Change by Erlend Egeberg Aasland :


--
keywords: +patch
pull_requests: +23466
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24681

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43350] [sqlite3] Active statements are reset twice in _pysqlite_query_execute()

[Erlend Egeberg Aasland]

New submission from Erlend Egeberg Aasland :

In _pysqlite_query_execute(), if the cursor already has a statement object, it 
is reset twice before the cache is queried.

--
components: Library (Lib)
messages: 387850
nosy: berker.peksag, erlendaasland, serhiy.storchaka
priority: normal
severity: normal
status: open
title: [sqlite3] Active statements are reset twice in _pysqlite_query_execute()
type: enhancement
versions: Python 3.10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43349] [doc] incorrect tuning(7) manpage link

[Erlend Egeberg Aasland]

Change by Erlend Egeberg Aasland :


--
keywords: +patch
pull_requests: +23465
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24680

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41837] Upgrade installers to OpenSSL 1.1.1j

[miss-islington]

miss-islington  added the comment:


New changeset 982e8ecbdf216bc1fa285a4ff45c84c6778856e5 by Miss Islington (bot) 
in branch '3.9':
bpo-41837: Update macOS installer build to use OpenSSL 1.1.1j. (GH-24677)
https://github.com/python/cpython/commit/982e8ecbdf216bc1fa285a4ff45c84c6778856e5


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41837] Upgrade installers to OpenSSL 1.1.1j

[miss-islington]

miss-islington  added the comment:


New changeset e2f6ed89aeaa0b723f45f914dba92e1b42518395 by Miss Islington (bot) 
in branch '3.8':
bpo-41837: Update macOS installer build to use OpenSSL 1.1.1j. (GH-24677)
https://github.com/python/cpython/commit/e2f6ed89aeaa0b723f45f914dba92e1b42518395


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com