[issue42540] Debug pymalloc crash when using os.fork() [regression]

[CendioOssman]

New submission from CendioOssman :

A python equivalent of the classical daemon() call started throwing an error 
from 3.8 when the debug hooks are active for pymalloc. If the tracing is also 
active it segfaults.

This simple example triggers it:


import os

def daemon():
pid = os.fork()
if pid != 0:
os._exit(0)

daemon()


The error given is:

Debug memory block at address p=0xf013d0: API '1'
0 bytes originally requested
The 7 pad bytes at p-7 are not all FORBIDDENBYTE (0xfd):
at p-7: 0x00 *** OUCH
at p-6: 0x00 *** OUCH
at p-5: 0x00 *** OUCH
at p-4: 0x00 *** OUCH
at p-3: 0x00 *** OUCH
at p-2: 0x00 *** OUCH
at p-1: 0x00 *** OUCH
Because memory is corrupted at the start, the count of bytes requested
   may be bogus, and checking the trailing pad bytes may segfault.
The 8 pad bytes at tail=0xf013d0 are not all FORBIDDENBYTE (0xfd):
at tail+0: 0x01 *** OUCH
at tail+1: 0x00 *** OUCH
at tail+2: 0x00 *** OUCH
at tail+3: 0x00 *** OUCH
at tail+4: 0x00 *** OUCH
at tail+5: 0x00 *** OUCH
at tail+6: 0x00 *** OUCH
at tail+7: 0x00 *** OUCH

Enable tracemalloc to get the memory block allocation traceback

Fatal Python error: bad ID: Allocated using API '1', verified using API 'r'
Python runtime state: finalizing (tstate=0xf023b0)



Tested on Fedora, Ubuntu and RHEL with the same behaviour everwhere. Everything 
up to 3.8 works fine. 3.8 and 3.9 both exhibit the issue.

Since this is a very standard way of starting a daemon it should affect quite a 
few users. At the very least it makes it annoying to use development mode to 
catch other issues.

--
components: Interpreter Core
messages: 382314
nosy: CendioOssman
priority: normal
severity: normal
status: open
title: Debug pymalloc crash when using os.fork() [regression]
type: crash
versions: Python 3.10, Python 3.8, Python 3.9

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

[issue41840] [regression] symtable.Symbol.is_local() is no longer True for bound global symbols

[CendioOssman]

New submission from CendioOssman :

So Issue40196 (and PR 19391) broke things for us here as Symbol.is_local() no 
longer works properly for symbols on the global/module scope.

Previously it would return True for all global symbols that were bound. Now it 
only returns True when the symbol is not used in any other scope. This means we 
cannot tell the difference between globals that are from the module itself, and 
globals that come in via imports.

This also seems to contradict this part of the language reference:

"(The variables of the module code block are local and global.)"

https://docs.python.org/3/reference/executionmodel.html

I don't see any clean workaround as there is no Symbol.is_bound() that could be 
used instead.

(inb4 https://xkcd.com/1172/)

--
components: Library (Lib)
messages: 377373
nosy: CendioOssman
priority: normal
severity: normal
status: open
title: [regression] symtable.Symbol.is_local() is no longer True for bound 
global symbols
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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