[issue31200] address sanitizer build fails

[STINNER Victor]

STINNER Victor  added the comment:

FYI there is bpo-1635741 which tries to cleanup more things at Python exit.

--
nosy: +vstinner

___
Python tracker 

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

[issue31200] address sanitizer build fails

[Julien Palard]

Change by Julien Palard :


--
pull_requests: +13952
pull_request: https://github.com/python/cpython/pull/13168

___
Python tracker 

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

[issue31200] address sanitizer build fails

[Julien Palard]

Julien Palard  added the comment:

Tried to reproduce it again, on master, but this does no longer segfault nor 
report leakages (as long as I use __INSURE__ using make -j18 profile-opt 
CFLAGS='-D__INSURE__') nor fail at build time.

There's still a few memory warnings while running tests (subinterpreters and 
things).

So I'm closing this (no build issue), thanks for reporting.

--
resolution:  -> works for me
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

[issue31200] address sanitizer build fails

[Julien Palard]

Julien Palard added the comment:

Segfault occur in Include/object.h line 1054:

#define Py_TRASHCAN_SAFE_BEGIN(op) \
do { \
PyThreadState *_tstate = PyThreadState_GET(); \
if (_tstate->trash_delete_nesting < PyTrash_UNWIND_LEVEL) { \
⧺_tstate->trash_delete_nesting;
/* The body of the deallocator is here. */

the _tstate is null at this moment.

It's NULL because in the main, right before the 
_Py_ReleaseInternedUnicodeStrings there's a call to Py_FinalizeEx which calls 
PyThreadState_Swap(NULL), see pylifecycle.c:1097:

/* Delete current thread. After this, many C API calls become crashy. */
PyThreadState_Swap(∅);

But there's probably still references to strings before the Py_FinalizeEx so it 
does not make sense to garbage collect before it.

Maybe make Py_TRASHCAN_SAFE_BEGIN more robust by disabling the counter when the 
state is NULL?

--

___
Python tracker 

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

[issue31200] address sanitizer build fails

[Julien Palard]

Julien Palard added the comment:

Some (most?) of them looks to be unicode strings, and according to the very end 
of the main function:

#ifdef __INSURE__
/* Insure++ is a memory analysis tool that aids in discovering
 * memory leaks and other memory problems.  On Python exit, the
 * interned string dictionaries are flagged as being in use at exit
 * (which it is).  Under normal circumstances, this is fine because
 * the memory will be automatically reclaimed by the system.  Under
 * memory debugging, it's a huge source of useless noise, so we
 * trade off slower shutdown for less distraction in the memory
 * reports.  -baw
 */
_Py_ReleaseInternedUnicodeStrings();
#endif /* __INSURE__ */

So, to ensure everything is as expected, I compiled with the __INSURE__ flag, 
and got:

releasing 1894 interned strings
total size of all interned strings: 17945/0 mortal/immortal
ASAN:DEADLYSIGNAL
=
==23814==ERROR: AddressSanitizer: SEGV on unknown address 0x00a0 (pc 
0x5575b1c16904 bp 0x7ffe1c4f1f60 sp 0x7ffe1c4f1f40 T0)
#0 0x5575b1c16903 in list_dealloc 
(/home/mdk/Downloads/cpython/python+0x524903)
#1 0x5575b1bf287d in _Py_Dealloc 
(/home/mdk/Downloads/cpython/python+0x50087d)
#2 0x5575b1c3daca in _Py_ReleaseInternedUnicodeStrings 
(/home/mdk/Downloads/cpython/python+0x54baca)
#3 0x5575b206c0d3 in Py_Main (/home/mdk/Downloads/cpython/python+0x97a0d3)
#4 0x5575b206d1d2 in main (/home/mdk/Downloads/cpython/python+0x97b1d2)
#5 0x7f5ed0b622b0 in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#6 0x5575b1b1f8d9 in _start (/home/mdk/Downloads/cpython/python+0x42d8d9)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/home/mdk/Downloads/cpython/python+0x524903) 
in list_dealloc
==23814==ABORTING

Which in this case does not looks normal.

--

___
Python tracker 

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

[issue31200] address sanitizer build fails

[Julien Palard]

Julien Palard added the comment:

Are you sure you build is failing? It looks like it succeeded, if we only speak 
about the build.

You're seeing AddressSanitizer reports because, during the build, the built 
python is used. Like in `./python -E -S -m sysconfig --generate-posix-vars`.

So if you see AddressSanitizer output, it's because a `./python` has been 
successfully built and used.

The built cpython with AddressSanitizer however reports leaks, which is 
probably reproductible by running, typically:

  ./python -c ''

--
nosy: +mdk

___
Python tracker 

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

[issue31200] address sanitizer build fails

[Paulo Matos]

New submission from Paulo Matos:

Build with address sanitizer fails miserably.

Configuration in Fedora 26. I attach config.log and the output of 
$ ../configure --with-assertions --with-lto --with-pydebug 
--with-address-sanitizer --disable-ipv6
$ make -j18 profile-opt

--
components: Build
files: files.zip
messages: 300240
nosy: pmatos
priority: normal
severity: normal
status: open
title: address sanitizer build fails
type: compile error
Added file: http://bugs.python.org/file47081/files.zip

___
Python tracker 

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