building python 2.7.15 on archlinux32 (the i686 branch of archlinux) from source succeeds, but running the testsuite (with some segfaulting tests disabled - see issue34095) results in an assertion error:

test_wrongsize (test.test_audioop.TestAudioop) ... test test_audioop failed -- Traceback (most recent call last):
  File "/home/vagrant/python2/src/Python-2.7.15/Lib/test/test_audioop.py", line 48, in test_max
    self.assertEqual(audioop.max(p(minvalues[w]), w), -minvalues[w])
AssertionError: -2147483648 != 2147483648L

ok

======================================================================
FAIL: test_max (test.test_audioop.TestAudioop)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/vagrant/python2/src/Python-2.7.15/Lib/test/test_audioop.py", line 48, in test_max
    self.assertEqual(audioop.max(p(minvalues[w]), w), -minvalues[w])
AssertionError: -2147483648 != 2147483648L



The commands leading to this are:

  cd Python-${pkgver}

  # Temporary workaround for FS#22322
  # See http://bugs.python.org/issue10835 for upstream report
  sed -i "/progname =/s/python/python${_pybasever}/" Python/pythonrun.c

  # Enable built-in SQLite module to load extensions (fix FS#22122)
  sed -i "/SQLITE_OMIT_LOAD_EXTENSION/d" setup.py

  # FS#23997
  sed -i -e "s|^#.* /usr/local/bin/python|#!/usr/bin/python2|" Lib/cgi.py

  sed -i "s/python2.3/python2/g" Lib/distutils/tests/test_build_scripts.py \
    Lib/distutils/tests/test_install_scripts.py

  # Ensure that we are using the system copy of various libraries (expat, zlib and libffi),
  # rather than copies shipped in the tarball
  rm -r Modules/expat
  rm -r Modules/zlib
  rm -r Modules/_ctypes/{darwin,libffi}*

  # clean up #!s
  find . -name '*.py' | \
    xargs sed -i "s|#[ ]*![ ]*/usr/bin/env python$|#!/usr/bin/env python2|"

  # Workaround asdl_c.py/makeopcodetargets.py errors after we touched the shebangs
  touch Include/Python-ast.h Python/Python-ast.c Python/opcode_targets.h

  # FS#48761
  # http://bugs.python.org/issue25750
  patch -Np1 -i ../descr_ref.patch

  export OPT="${CFLAGS}"
  ./configure --prefix=/usr \
              --enable-shared \
              --with-threads \
              --enable-optimizations \
              --with-lto \
              --enable-ipv6 \
              --enable-unicode=ucs4 \
              --with-system-expat \
              --with-system-ffi \
              --with-dbmliborder=gdbm:ndbm \
              --without-ensurepip

  make

  LD_LIBRARY_PATH="${srcdir}/Python-${pkgver}":${LD_LIBRARY_PATH} \
    xvfb-run "${srcdir}/Python-${pkgver}/python" -m test.regrtest -v -uall -x test_idle test_bytes test_str test_string test_unicode test_userstring test_tuple test_tk test_ttk_guionly test_ctypes 2>&1 | tee log.reduced

It seems like you are using [GCC 8.1.1 20180531]. Can you please run the following command and attach the created "pythoninfo" file to his issue?

./python -m test.pythoninfo > pythoninfo

I'm looking for your CFLAGS.

I guess that the issue is specific to 32-bit, but we have many "x86" buildbots building Python on various compilers and running the test suite, and all these buildbots are green (success).

yes, I'm using gcc (GCC) 8.1.1 20180531
I attached the created pythoninfo

Extract of attached test.pythoninfo output:

sys.maxsize: 2147483647
sysconfig[PY_CFLAGS]: -fno-strict-aliasing -march=i686 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -DNDEBUG -march=i686 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -I. -IInclude -I./Include -D_FORTIFY_SOURCE=2 -fPIC -DPy_BUILD_CORE

I tried to reproduce the issue on my x86_64 Fedora 28 (64-bit) using:

   ./configure CFLAGS="-m32" LDFLAGS="-m32" && make

But I failed to reproduce the issue. I also tried to add "-fstack-protector-strong -fno-plt" but I still fail to reproduce the bug.

On interesting thing is that your CFLAGS don't contain -fwrapv. You can try the following command to check if gcc -v --help contains -fwrapv?

"gcc -v --help|grep -- -fwrapv"

With my french locale, for example, I see:

  -fwrapv                     Supposer que le débordement de l'arithmétique signée boucle sur la plage accessible.

You may try to force -fwrapv using ./configure CFLAGS="-fwrapv" or directly by adding directly the option to the OPT variable in Makefile. Example of options on my x86_64 Fedora and "./configure":

OPT=		-DNDEBUG -g -fwrapv -O3 -Wall
BASECFLAGS=	 -Wno-unused-result -Wsign-compare
CONFIGURE_CFLAGS_NODIST= -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration

Note: When Python is compiled with --with-pydebug, -fwrapv is not used.

Note: Your CFLAGS use -O2 whereas Python uses -O3 by default in release mode.

I installed Fedora 28 in 32-bit (GCC 8.1.1) in a VM to try to reproduce the bug, but I failed to reproduce it.

Erich Eckner: IMHO your issue comes from a C flag. Try to loop on:

touch Modules/audioop.c && make && ./python -m test test_audioop

And remove flags from PY_CFLAGS in Makefile, one by one, until the bug goes away, to try to identify which C flags causes your issue.

yes, indeed, I just tested with your three flags-variables set and the build+test succeeded - I'll have to figure out what the minimal change is, though :-)

> yes, indeed, I just tested with your three flags-variables set and the build+test succeeded - I'll have to figure out what the minimal change is, though :-)

Yeah, it would be great if you can find the C flag which fixes your issue. I bet on -fwrapv.

yes, you were absolutely right: just adding "-fwrapv" to $OPT is enough.

Ok, is this something, we at archlinux32 need to opt in for, or is this something, that the configure script should add for x86?

Mark, Serhiy, Gregory and other fanboys of Undefined Behaviour: it seems like audioop is miscompiled on x86 (32-bit) without -fwrapv :-)

IIRC that we decided that CPython and extension modules always require -fwrapv.

https://github.com/python/cpython/blob/2.7/configure.ac#L1067

appears to add -fwrapv as desired if the gcc or clang version being used supports it.

ah, that would explain, why we don't get it set automatically on archlinux32 - there's "export OPT=$CFLAGS" right infront of ./configure ... - so $OPT is set and thus, -fwrapv is not appended

yep.  i'm going to close this, it seems arch specific.  there isn't much we can realistically do to prevent people overriding things to their peril for configure or make. :)

stage: resolved

messages: + msg321584