AddressSanitizer: SEGV on unknown address 0x000000000000...

[Jeffrey Walton]

I'm trying to run Python-3.4.0rc3 through Asan.

The package was only mildly difficult to build. The only un-ordinary
part was I had to add some of the sanitizer libraries to LIBS due to
undefined symbols like __asan_report8 when building the Python archive
libpython3.4m.a:

export CC=/usr/local/bin/clang
export CXX=/usr/local/bin/clang++
export CFLAGS="-g3 -fsanitize=address"
export CXXFLAGS="-g3 -fsanitize=address"
export LIBS="/usr/local/lib/clang/3.4/lib/linux/libclang_rt.full-x86_64.a \
/usr/local/lib/clang/3.4/lib/linux/libclang_rt.asan-x86_64.a \
/usr/local/lib/clang/3.4/lib/linux/libclang_rt.san-x86_64.a"

When I run `make test`, I run into some problems (shown below). Does
anyone have an idea why PC is 0x00000000?

Thanks in advance.

**********

$ make test | asan_symbolize.py
...

running build_scripts
copying and adjusting .../Python-3.4.0rc3/Tools/scripts/pydoc3 ->
build/scripts-3.4
copying and adjusting .../Python-3.4.0rc3/Tools/scripts/idle3 ->
build/scripts-3.4
ASAN:SIGSEGV
=================================================================
==16760==ERROR: AddressSanitizer: SEGV on unknown address
0x000000000000 (pc 0x000000000000 sp 0x7fff67622868 bp 0x7fff67622890
T0)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ??:0 ??
==16760==ABORTING
make: *** [test] Error 1
copying and adjusting .../Python-3.4.0rc3/Tools/scripts/2to3 ->
build/scripts-3.4
copying and adjusting .../Python-3.4.0rc3/Tools/scripts/pyvenv ->
build/scripts-3.4
changing mode of build/scripts-3.4/pydoc3 from 644 to 755
changing mode of build/scripts-3.4/idle3 from 644 to 755
changing mode of build/scripts-3.4/2to3 from 644 to 755
changing mode of build/scripts-3.4/pyvenv from 644 to 755
renaming build/scripts-3.4/pydoc3 to build/scripts-3.4/pydoc3.4
renaming build/scripts-3.4/idle3 to build/scripts-3.4/idle3.4
renaming build/scripts-3.4/2to3 to build/scripts-3.4/2to3-3.4
renaming build/scripts-3.4/pyvenv to build/scripts-3.4/pyvenv-3.4
./python -E -c 'import sys ; from sysconfig import get_platform ;
print(get_platform()+"-"+sys.version[0:3])' >platform
./python ./Tools/scripts/run_tests.py
$

[Yuri Gribov]

> Does
> anyone have an idea why PC is 0x00000000?

I think that Asan initialization code (__asan_init) didn't run so
glibc interceptors were not set up.

> The only un-ordinary
> part was I had to add some of the sanitizer libraries to LIBS due to
> undefined symbols like __asan_report8 when building the Python archive
> libpython3.4m.a:

I don't think this is the right way to go (actually, I believe this is
the cause of error). You need to make sure that python executable is
linked with -fsanitize-address - this flag will pass all the necessary
libs and flags to linker (it's non-trivial!).

@Kostya: can we add a check in SEGV handler and detect the case when
pc == NULL? We could report something like "Looks like Asan runtime
wasn't linked properly, please check your link flags"?

-Y

[Konstantin Serebryany]

On Sat, Mar 15, 2014 at 11:36 AM, Yuri Gribov <tetr...@gmail.com> wrote:

> Does
> anyone have an idea why PC is 0x00000000?

I think that Asan initialization code (__asan_init) didn't run so
glibc interceptors were not set up.

> The only un-ordinary
> part was I had to add some of the sanitizer libraries to LIBS due to
> undefined symbols like __asan_report8 when building the Python archive
> libpython3.4m.a:

I don't think this is the right way to go (actually, I believe this is
the cause of error). You need to make sure that python executable is
linked with -fsanitize-address - this flag will pass all the necessary
libs and flags to linker (it's non-trivial!).

Yep. 

 

@Kostya: can we add a check in SEGV handler and detect the case when
pc == NULL? We could report something like "Looks like Asan runtime
wasn't linked properly, please check your link flags"?

We see the stack trace from asan's SEGV handler, so __asan_init was already called. 

PC could be 0 in different cases (just some user function pointer is NULL)

--kcc 

 

-Y

--
You received this message because you are subscribed to the Google Groups "address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to address-saniti...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[nolo...@gmail.com]

On Saturday, March 15, 2014 3:36:25 AM UTC-4, Yuri Gribov wrote:

> Does
> anyone have an idea why PC is 0x00000000?

I think that Asan initialization code (__asan_init) didn't run so
glibc interceptors were not set up.

> The only un-ordinary
> part was I had to add some of the sanitizer libraries to LIBS due to
> undefined symbols like __asan_report8 when building the Python archive
> libpython3.4m.a:

I don't think this is the right way to go (actually, I believe this is
the cause of error). You need to make sure that python executable is
linked with -fsanitize-address - this flag will pass all the necessary
libs and flags to linker (it's non-trivial!).

Thanks Yuri. Yes, agreed about the usage.

So I'm clear: Clang was installed in /usr/local. The sanitizers are located in /usr/local/lib/clang/3.4/lib/linux/. That's not a problem, correct?

Oh, and forgot to mention (sorry about that)... This is Clang 3.4 from the LLVM downloads page.

Let me go back and turn some knobs on the makefile and see if I can use it correctly (tuning makefiles for Asan/Ubsan is becoming a black art ;)

Jeff

[nolo...@gmail.com]

On Saturday, March 15, 2014 3:36:25 AM UTC-4, Yuri Gribov wrote:

> Does
> anyone have an idea why PC is 0x00000000?

I think that Asan initialization code (__asan_init) didn't run so
glibc interceptors were not set up.

> The only un-ordinary
> part was I had to add some of the sanitizer libraries to LIBS due to
> undefined symbols like __asan_report8 when building the Python archive
> libpython3.4m.a:

I don't think this is the right way to go (actually, I believe this is
the cause of error). You need to make sure that python executable is
linked with -fsanitize-address - this flag will pass all the necessary
libs and flags to linker (it's non-trivial!).

You were right Yuri. I found a linker invocation that did not use any flags.

For completeness, here it is (the mods would be applied in the top level Makefile after ./configure):

# Build the interpreter
$(BUILDPYTHON):    Modules/python.o $(LIBRARY) $(LDLIBRARY) $(PY3LIBRARY)
    $(LINKCC) -g3 -fsanitize=address $(PY_LDFLAGS) $(LINKFORSHARED) -o $@ Modules/python.o $(BLDLIBRARY) $(LIBS) $(MODLIBS) $(SYSLIBS) $(LDLAST)

Thanks for the help.

Jeff

[Yuri Gribov]

On Sat, Mar 15, 2014 at 12:32 PM, Konstantin Serebryany
<konstantin....@gmail.com> wrote:
> We see the stack trace from asan's SEGV handler, so __asan_init was already called.

True, I wonder what could go wrong then?

-Y

[Yuri Gribov]

> Thanks for the help.

Np, glad to help.

-Y