Re: F21 system GCC changed to 4.9.0 prerelease

2014-04-12 Thread Zoltan Boszormenyi 

2014-04-10 19:38 keltezéssel, Orion Poplawski írta:

On 04/10/2014 04:23 AM, Jakub Jelinek wrote:

Hi!

FYI, gcc in rawhide has been upgraded to 4.9.0 prerelease,
please visit http://gcc.gnu.org/gcc-4.9/porting_to.html if your
package no longer builds.  To investigate runtime rather than compile time
issues, please consider using temporarily -fsanitize=undefined and/or
-fsanitize=address to look for undefined behavior in the packages
you own.

Jakub


I think I've found a regression in gfortran with list-directed reading
from character arrays: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60810
unless this is some kind of new standards compliance, but this seems to
have worked forever.


Any project I tried with
   ./configure CFLAGS=-fsanitize=undefined -fsanitize=address
fails with:

checking for gcc... gcc
checking whether the C compiler works... no

config.log reveals that libasan.so and libubsan.so are missing from the system.
yum install lib{a,ub}san.{i686,x86_64} fixed it. Shouldn't gcc and gcc-c++
packages require these libraries?

Best regards,
Zoltán Böszörményi

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 system GCC changed to 4.9.0 prerelease

2014-04-12 Thread Zbigniew Jędrzejewski-Szmek 
On Sat, Apr 12, 2014 at 11:41:48AM +0200, Zoltan Boszormenyi wrote:
 Any project I tried with
./configure CFLAGS=-fsanitize=undefined -fsanitize=address
 fails with:
 
 checking for gcc... gcc
 checking whether the C compiler works... no
 
 config.log reveals that libasan.so and libubsan.so are missing from the 
 system.
 yum install lib{a,ub}san.{i686,x86_64} fixed it. Shouldn't gcc and gcc-c++
 packages require these libraries?
No, it's just those options that require the libraries. IMO, if we
multiply the number of saniter libraries (so far 3 and growing), by
the number of possible architectures supported by the same compiler, we
quickly get into a larger dependency tree then something you want to
install *always*.

Zbyszek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 system GCC changed to 4.9.0 prerelease

2014-04-11 Thread Panu Matilainen 

On 04/10/2014 05:38 PM, Richard W.M. Jones wrote:

On Thu, Apr 10, 2014 at 12:23:07PM +0200, Jakub Jelinek wrote:

To investigate runtime rather than compile time
issues, please consider using temporarily -fsanitize=undefined and/or
-fsanitize=address to look for undefined behavior in the packages
you own.


Which is this in case anyone else was wondering:

   '-fsanitize=address'
  Enable AddressSanitizer, a fast memory error detector.  Memory
  access instructions will be instrumented to detect out-of-bounds
  and use-after-free bugs.  See
  http://code.google.com/p/address-sanitizer/ for more details.
  The run-time behavior can be influenced using the 'ASAN_OPTIONS'
  environment variable; see
  https://code.google.com/p/address-sanitizer/wiki/Flags#Run-time_flags
  for a list of supported options.


Also in case anybody else wonders about gcc failing to recognize these 
options, you'll need to add BuildRequires for these: libasan for 
-fsanitize=address and libubsan for -fsanitize=undefined (and similarly 
for leak and thread sanitizers )


- Panu -

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 system GCC changed to 4.9.0 prerelease

2014-04-11 Thread Jakub Jelinek 
On Fri, Apr 11, 2014 at 11:32:53AM +0300, Panu Matilainen wrote:
 On 04/10/2014 05:38 PM, Richard W.M. Jones wrote:
 On Thu, Apr 10, 2014 at 12:23:07PM +0200, Jakub Jelinek wrote:
 To investigate runtime rather than compile time
 issues, please consider using temporarily -fsanitize=undefined and/or
 -fsanitize=address to look for undefined behavior in the packages
 you own.
 
 Which is this in case anyone else was wondering:
 
'-fsanitize=address'
   Enable AddressSanitizer, a fast memory error detector.  Memory
   access instructions will be instrumented to detect out-of-bounds
   and use-after-free bugs.  See
   http://code.google.com/p/address-sanitizer/ for more details.
   The run-time behavior can be influenced using the 'ASAN_OPTIONS'
   environment variable; see
   https://code.google.com/p/address-sanitizer/wiki/Flags#Run-time_flags
   for a list of supported options.
 
 Also in case anybody else wonders about gcc failing to recognize
 these options, you'll need to add BuildRequires for these: libasan
 for -fsanitize=address and libubsan for -fsanitize=undefined (and
 similarly for leak and thread sanitizers )

Yeah.  But, note that the sanitizers are meant primarily for development,
not for production, and especially -fsanitize=thread and to some extent
-fsanitize=address aren't completely cheap, so if you do that, please do
so temporarily and don't forget to disable it again for production.

Jakub
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 system GCC changed to 4.9.0 prerelease

2014-04-11 Thread Tim Waugh 
This new checking looks really powerful.

Unfortunately, I'm seeing a build failure for libgphoto2 that I'm having
a hard time making sense of:

http://kojipkgs.fedoraproject.org//work/tasks/7196/6727196/root.log

DEBUG util.py:331:  Executing command: ['fedpkg', 'sources'] with env
{'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash',
'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'echo -n mock-chroot', 'HOME':
'/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin'}
DEBUG util.py:281:  ==15737==AddressSanitizer CHECK failed: 
../../../../libsanitizer/asan/asan_globals.cc:91 
((AddrIsAlignedByGranularity(g-beg))) != (0) (0x0, 0x0)
DEBUG util.py:281:  #0 0xb583d21b (/lib/libasan.so.1+0x6121b)
DEBUG util.py:281:  #1 0xb5841a8b in __sanitizer::CheckFailed(char const*, 
int, char const*, unsigned long long, unsigned long long) 
(/lib/libasan.so.1+0x65a8b)
DEBUG util.py:281:  #2 0xb57fb01b in __asan_register_globals 
(/lib/libasan.so.1+0x1f01b)
DEBUG util.py:281:  #3 0xb6f14877 in call_init.part.0 
(/lib/ld-linux-armhf.so.3+0x11877)
DEBUG util.py:281:  #4 0xb6f149d3 in _dl_init 
(/lib/ld-linux-armhf.so.3+0x119d3)
DEBUG util.py:281:  #5 0xb6f199e7 in dl_open_worker 
(/lib/ld-linux-armhf.so.3+0x169e7)
DEBUG util.py:281:  #6 0xb6f14723 in _dl_catch_error 
(/lib/ld-linux-armhf.so.3+0x11723)
DEBUG util.py:281:  #7 0xb6f18f3f in _dl_open 
(/lib/ld-linux-armhf.so.3+0x15f3f)
DEBUG util.py:281:  #8 0xb6d58d03 in dlopen_doit (/lib/libdl.so.2+0xd03)
DEBUG util.py:281:  #9 0xb6f14723 in _dl_catch_error 
(/lib/ld-linux-armhf.so.3+0x11723)
DEBUG util.py:281:  #10 0xb6d594c7 in _dlerror_run (/lib/libdl.so.2+0x14c7)
DEBUG util.py:281:  #11 0xb6d58dcf in __dlopen (/lib/libdl.so.2+0xdcf)
DEBUG util.py:281:  #12 0xb6e8055f in _PyImport_GetDynLoadFunc 
(/lib/libpython2.7.so.1.0+0xfa55f)
DEBUG util.py:281:  #13 0xb6e6803b in _PyImport_LoadDynamicModule 
(/lib/libpython2.7.so.1.0+0xe203b)
DEBUG util.py:281:  #14 0xb6e65e7f (/lib/libpython2.7.so.1.0+0xdfe7f)
DEBUG util.py:281:  #15 0xb6e660d3 (/lib/libpython2.7.so.1.0+0xe00d3)
DEBUG util.py:281:  #16 0xb6e66bab in PyImport_ImportModuleLevel 
(/lib/libpython2.7.so.1.0+0xe0bab)
DEBUG util.py:281:  #17 0xb6e4adf3 (/lib/libpython2.7.so.1.0+0xc4df3)
DEBUG util.py:281:  #18 0xb6def51b in PyCFunction_Call 
(/lib/libpython2.7.so.1.0+0x6951b)
DEBUG util.py:281:  #19 0xb6db1d6f in PyObject_Call 
(/lib/libpython2.7.so.1.0+0x2bd6f)
DEBUG util.py:281:  #20 0xb6e4ceab in PyEval_CallObjectWithKeywords 
(/lib/libpython2.7.so.1.0+0xc6eab)
DEBUG util.py:281:  #21 0xb6e4fb63 in PyEval_EvalFrameEx 
(/lib/libpython2.7.so.1.0+0xc9b63)
DEBUG util.py:281:  #22 0xb6e53c3f in PyEval_EvalCodeEx 
(/lib/libpython2.7.so.1.0+0xcdc3f)
DEBUG util.py:281:  #23 0xb6e53e03 in PyEval_EvalCode 
(/lib/libpython2.7.so.1.0+0xcde03)
DEBUG util.py:281:  #24 0xb6e64e93 in PyImport_ExecCodeModuleEx 
(/lib/libpython2.7.so.1.0+0xdee93)
DEBUG util.py:281:  #25 0xb6e6511b (/lib/libpython2.7.so.1.0+0xdf11b)
DEBUG util.py:281:  #26 0xb6e666b7 (/lib/libpython2.7.so.1.0+0xe06b7)
DEBUG util.py:281:  #27 0xb6e65e7f (/lib/libpython2.7.so.1.0+0xdfe7f)
DEBUG util.py:281:  #28 0xb6e6612b (/lib/libpython2.7.so.1.0+0xe012b)
DEBUG util.py:281:  #29 0xb6e66b5f in PyImport_ImportModuleLevel 
(/lib/libpython2.7.so.1.0+0xe0b5f)
DEBUG util.py:281:  #30 0xb6e4adf3 (/lib/libpython2.7.so.1.0+0xc4df3)
DEBUG util.py:281:  #31 0xb6def51b in PyCFunction_Call 
(/lib/libpython2.7.so.1.0+0x6951b)
DEBUG util.py:281:  #32 0xb6db1d6f in PyObject_Call 
(/lib/libpython2.7.so.1.0+0x2bd6f)
DEBUG util.py:281:  #33 0xb6e4ceab in PyEval_CallObjectWithKeywords 
(/lib/libpython2.7.so.1.0+0xc6eab)
DEBUG util.py:281:  #34 0xb6e4fb63 in PyEval_EvalFrameEx 
(/lib/libpython2.7.so.1.0+0xc9b63)
DEBUG util.py:281:  #35 0xb6e53c3f in PyEval_EvalCodeEx 
(/lib/libpython2.7.so.1.0+0xcdc3f)
DEBUG util.py:281:  #36 0xb6e53e03 in PyEval_EvalCode 
(/lib/libpython2.7.so.1.0+0xcde03)
DEBUG util.py:281:  #37 0xb6e64e93 in PyImport_ExecCodeModuleEx 
(/lib/libpython2.7.so.1.0+0xdee93)
DEBUG util.py:281:  #38 0xb6e6511b (/lib/libpython2.7.so.1.0+0xdf11b)
DEBUG util.py:281:  #39 0xb6e666b7 (/lib/libpython2.7.so.1.0+0xe06b7)
DEBUG util.py:281:  #40 0xb6e65e7f (/lib/libpython2.7.so.1.0+0xdfe7f)
DEBUG util.py:281:  #41 0xb6e6612b (/lib/libpython2.7.so.1.0+0xe012b)
DEBUG util.py:281:  #42 0xb6e66b5f in PyImport_ImportModuleLevel 
(/lib/libpython2.7.so.1.0+0xe0b5f)
DEBUG util.py:281:  #43 0xb6e4adf3 (/lib/libpython2.7.so.1.0+0xc4df3)
DEBUG util.py:281:  #44 0xb6def51b in PyCFunction_Call 
(/lib/libpython2.7.so.1.0+0x6951b)
DEBUG util.py:281:  #45 0xb6db1d6f in PyObject_Call 
(/lib/libpython2.7.so.1.0+0x2bd6f)
DEBUG util.py:281:  #46 0xb6e4ceab in PyEval_CallObjectWithKeywords 
(/lib/libpython2.7.so.1.0+0xc6eab)
DEBUG util.py:281:  #47 0xb6e4fb63 in PyEval_EvalFrameEx 
(/lib/libpython2.7.so.1.0+0xc9b63)
DEBUG

Re: F21 system GCC changed to 4.9.0 prerelease

2014-04-11 Thread Josh Boyer 
On Fri, Apr 11, 2014 at 5:10 AM, Jakub Jelinek ja...@redhat.com wrote:
 On Fri, Apr 11, 2014 at 11:32:53AM +0300, Panu Matilainen wrote:
 On 04/10/2014 05:38 PM, Richard W.M. Jones wrote:
 On Thu, Apr 10, 2014 at 12:23:07PM +0200, Jakub Jelinek wrote:
 To investigate runtime rather than compile time
 issues, please consider using temporarily -fsanitize=undefined and/or
 -fsanitize=address to look for undefined behavior in the packages
 you own.
 
 Which is this in case anyone else was wondering:
 
'-fsanitize=address'
   Enable AddressSanitizer, a fast memory error detector.  Memory
   access instructions will be instrumented to detect out-of-bounds
   and use-after-free bugs.  See
   http://code.google.com/p/address-sanitizer/ for more details.
   The run-time behavior can be influenced using the 'ASAN_OPTIONS'
   environment variable; see
   
  https://code.google.com/p/address-sanitizer/wiki/Flags#Run-time_flags
   for a list of supported options.

 Also in case anybody else wonders about gcc failing to recognize
 these options, you'll need to add BuildRequires for these: libasan
 for -fsanitize=address and libubsan for -fsanitize=undefined (and
 similarly for leak and thread sanitizers )

 Yeah.  But, note that the sanitizers are meant primarily for development,
 not for production, and especially -fsanitize=thread and to some extent
 -fsanitize=address aren't completely cheap, so if you do that, please do
 so temporarily and don't forget to disable it again for production.

Seems they were enabled for RPM in rawhide and now a mock chroot fails
to init because RPM explodes.  This is from a noarch (which is run on
an ARM builder) build from a scratch build.

DEBUG util.py:331:  Executing command: ['rpm', '-Uvh', '--nodeps',
'/builddir/build/originals/kernel-3.15.0-0.rc0.git12.1.fc21.src.rpm']
with env {'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL':
'/bin/bash', 'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'echo -n
mock-chroot', 'HOME': '/builddir', 'PATH':
'/usr/bin:/bin:/usr/sbin:/sbin'}
DEBUG util.py:281:  ==13953==AddressSanitizer CHECK failed:
../../../../libsanitizer/asan/asan_globals.cc:91
((AddrIsAlignedByGranularity(g-beg))) != (0) (0x0, 0x0)
DEBUG util.py:281:  #0 0xb6a6d21b (/lib/libasan.so.1+0x6121b)
DEBUG util.py:281:  #1 0xb6a71a8b in __sanitizer::CheckFailed(char
const*, int, char const*, unsigned long long, unsigned long long)
(/lib/libasan.so.1+0x65a8b)
DEBUG util.py:281:  #2 0xb6a2b01b in __asan_register_globals
(/lib/libasan.so.1+0x1f01b)
DEBUG util.py:281:  #3 0xb6f11877 in call_init.part.0
(/lib/ld-linux-armhf.so.3+0x11877)
DEBUG util.py:281:  #4 0xb6f119d3 in _dl_init
(/lib/ld-linux-armhf.so.3+0x119d3)
DEBUG util.py:281:  #5 0xb6f00bc3 (/lib/ld-linux-armhf.so.3+0xbc3)
DEBUG util.py:371:  Child return code was: 1

Full scratch build:

http://koji.fedoraproject.org/koji/taskinfo?taskID=6727256

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 system GCC changed to 4.9.0 prerelease

2014-04-11 Thread Przemek Klosowski 

On 04/11/2014 05:10 AM, Jakub Jelinek wrote:

On Fri, Apr 11, 2014 at 11:32:53AM +0300, Panu Matilainen wrote:

On 04/10/2014 05:38 PM, Richard W.M. Jones wrote:

On Thu, Apr 10, 2014 at 12:23:07PM +0200, Jakub Jelinek wrote:

To investigate runtime rather than compile time
issues, please consider using temporarily -fsanitize=undefined and/or
-fsanitize=address to look for undefined behavior in the packages
you own.

Which is this in case anyone else was wondering:

   '-fsanitize=address'
  Enable AddressSanitizer, a fast memory error detector.  Memory
  access instructions will be instrumented to detect out-of-bounds
  and use-after-free bugs.  See
  http://code.google.com/p/address-sanitizer/ for more details.
  The run-time behavior can be influenced using the 'ASAN_OPTIONS'
  environment variable; see
  https://code.google.com/p/address-sanitizer/wiki/Flags#Run-time_flags
  for a list of supported options.

Also in case anybody else wonders about gcc failing to recognize
these options, you'll need to add BuildRequires for these: libasan
for -fsanitize=address and libubsan for -fsanitize=undefined (and
similarly for leak and thread sanitizers )

Yeah.  But, note that the sanitizers are meant primarily for development,
not for production, and especially -fsanitize=thread and to some extent
-fsanitize=address aren't completely cheap, so if you do that, please do
so temporarily and don't forget to disable it again for production.

Jakub

FWIW, some liveCD like e.g. the Electronic Lab started failing because

libtool-2.4.2-23.fc21.i686 requires gcc = 4.8.2

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 system GCC changed to 4.9.0 prerelease

2014-04-11 Thread Dan Horák 
On Fri, 11 Apr 2014 09:16:33 -0400
Przemek Klosowski przemek.klosow...@nist.gov wrote:

 On 04/11/2014 05:10 AM, Jakub Jelinek wrote:
  On Fri, Apr 11, 2014 at 11:32:53AM +0300, Panu Matilainen wrote:
  On 04/10/2014 05:38 PM, Richard W.M. Jones wrote:
  On Thu, Apr 10, 2014 at 12:23:07PM +0200, Jakub Jelinek wrote:
  To investigate runtime rather than compile time
  issues, please consider using temporarily -fsanitize=undefined
  and/or -fsanitize=address to look for undefined behavior in the
  packages you own.
  Which is this in case anyone else was wondering:
 
 '-fsanitize=address'
Enable AddressSanitizer, a fast memory error detector.
  Memory access instructions will be instrumented to detect
  out-of-bounds and use-after-free bugs.  See
http://code.google.com/p/address-sanitizer/ for more
  details. The run-time behavior can be influenced using the
  'ASAN_OPTIONS' environment variable; see

  https://code.google.com/p/address-sanitizer/wiki/Flags#Run-time_flags
for a list of supported options.
  Also in case anybody else wonders about gcc failing to recognize
  these options, you'll need to add BuildRequires for these: libasan
  for -fsanitize=address and libubsan for -fsanitize=undefined (and
  similarly for leak and thread sanitizers )
  Yeah.  But, note that the sanitizers are meant primarily for
  development, not for production, and especially -fsanitize=thread
  and to some extent -fsanitize=address aren't completely cheap, so
  if you do that, please do so temporarily and don't forget to
  disable it again for production.
 
  Jakub
 FWIW, some liveCD like e.g. the Electronic Lab started failing because
 
 libtool-2.4.2-23.fc21.i686 requires gcc = 4.8.2

there is already libtool-2.4.2-24.fc21 that will fix it


Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 system GCC changed to 4.9.0 prerelease

2014-04-11 Thread Panu Matilainen 

On 04/11/2014 04:15 PM, Josh Boyer wrote:

On Fri, Apr 11, 2014 at 5:10 AM, Jakub Jelinek ja...@redhat.com wrote:

On Fri, Apr 11, 2014 at 11:32:53AM +0300, Panu Matilainen wrote:

On 04/10/2014 05:38 PM, Richard W.M. Jones wrote:

On Thu, Apr 10, 2014 at 12:23:07PM +0200, Jakub Jelinek wrote:

To investigate runtime rather than compile time
issues, please consider using temporarily -fsanitize=undefined and/or
-fsanitize=address to look for undefined behavior in the packages
you own.


Which is this in case anyone else was wondering:

   '-fsanitize=address'
  Enable AddressSanitizer, a fast memory error detector.  Memory
  access instructions will be instrumented to detect out-of-bounds
  and use-after-free bugs.  See
  http://code.google.com/p/address-sanitizer/ for more details.
  The run-time behavior can be influenced using the 'ASAN_OPTIONS'
  environment variable; see
  https://code.google.com/p/address-sanitizer/wiki/Flags#Run-time_flags
  for a list of supported options.


Also in case anybody else wonders about gcc failing to recognize
these options, you'll need to add BuildRequires for these: libasan
for -fsanitize=address and libubsan for -fsanitize=undefined (and
similarly for leak and thread sanitizers )


Yeah.  But, note that the sanitizers are meant primarily for development,
not for production, and especially -fsanitize=thread and to some extent
-fsanitize=address aren't completely cheap, so if you do that, please do
so temporarily and don't forget to disable it again for production.


Seems they were enabled for RPM in rawhide and now a mock chroot fails
to init because RPM explodes.  This is from a noarch (which is run on
an ARM builder) build from a scratch build.

DEBUG util.py:331:  Executing command: ['rpm', '-Uvh', '--nodeps',
'/builddir/build/originals/kernel-3.15.0-0.rc0.git12.1.fc21.src.rpm']
with env {'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL':
'/bin/bash', 'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'echo -n
mock-chroot', 'HOME': '/builddir', 'PATH':
'/usr/bin:/bin:/usr/sbin:/sbin'}
DEBUG util.py:281:  ==13953==AddressSanitizer CHECK failed:
../../../../libsanitizer/asan/asan_globals.cc:91
((AddrIsAlignedByGranularity(g-beg))) != (0) (0x0, 0x0)
DEBUG util.py:281:  #0 0xb6a6d21b (/lib/libasan.so.1+0x6121b)
DEBUG util.py:281:  #1 0xb6a71a8b in __sanitizer::CheckFailed(char
const*, int, char const*, unsigned long long, unsigned long long)
(/lib/libasan.so.1+0x65a8b)
DEBUG util.py:281:  #2 0xb6a2b01b in __asan_register_globals
(/lib/libasan.so.1+0x1f01b)
DEBUG util.py:281:  #3 0xb6f11877 in call_init.part.0
(/lib/ld-linux-armhf.so.3+0x11877)
DEBUG util.py:281:  #4 0xb6f119d3 in _dl_init
(/lib/ld-linux-armhf.so.3+0x119d3)
DEBUG util.py:281:  #5 0xb6f00bc3 (/lib/ld-linux-armhf.so.3+0xbc3)
DEBUG util.py:371:  Child return code was: 1

Full scratch build:

http://koji.fedoraproject.org/koji/taskinfo?taskID=6727256


Oh ... ¤#%#¤%#. I realized this blows up, fired a new build to disable 
the thing again ASAP. And thought it completed okay and kinda forgot 
about it:

http://koji.fedoraproject.org/koji/taskinfo?taskID=6726924

Built okay on everything but ARM, dunno why that is... but the buggy rpm 
needs untagging now (will do as soon as I get the expired certificate 
sorted, but if somebody beats me to it, feel free)


Apologies for the mess,

- Panu -


josh



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 system GCC changed to 4.9.0 prerelease

2014-04-11 Thread Jakub Jelinek 
On Fri, Apr 11, 2014 at 09:15:35AM -0400, Josh Boyer wrote:
 Seems they were enabled for RPM in rawhide and now a mock chroot fails
 to init because RPM explodes.  This is from a noarch (which is run on
 an ARM builder) build from a scratch build.

For -fsanitize=address (and -fsanitize=thread), it is usually needed that
if some shared library is instrumented with that, the binary linking against
that or especially dlopening such shared libraries is also instrumented (the
same).  So, I'd strongly recommend against enabling -fsanitize=address for
building of shared libraries some other packages might need to dlopen, do it
only in your own scratch builds, not in anything you install into rawhide.
The thing with these two is that libasan.so (or libtsan.so) needs to be
initialized very early, before other shared libraries that might be
instrumented run their constructors.
Also, -fsanitize=address has been tested much more on x86_64/i686 than on
other architectures.
And, -fsanitize=address is incompatible with -fsanitize=thread, you can only
have one kind of instrumentation from these in the whole process.

-fsanitize=undefined instrumented shared libraries can be dlopened just
fine, but don't forget to disable the instrumentations say after beta.

Jakub
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 system GCC changed to 4.9.0 prerelease

2014-04-11 Thread Jakub Jelinek 
On Fri, Apr 11, 2014 at 01:45:38PM +0100, Tim Waugh wrote:
 This new checking looks really powerful.
 
 Unfortunately, I'm seeing a build failure for libgphoto2 that I'm having
 a hard time making sense of:
 
 http://kojipkgs.fedoraproject.org//work/tasks/7196/6727196/root.log

I think Panu has a fixed rpm already built.
In any case, this particular failure looks like __asan_register_globals has
been called with some address of a global var not sufficiently (32-byte)
aligned, supposedly while dlopening librpm.so or some other library.
If somebody can reproduce it manually using rpm-4.11.2-6.fc21.armv7hl
outside of koji/mock and could put a breakpoint to __sanitizer::CheckFailed
and find out what value g-beg has at that point (i.e. what address
is misaligned) and what library/variable it points to, I could debug this
on the GCC side, but it is certainly something I've never seen on
x86_64/i686 (nor ppc/ppc64) yet.

 DEBUG util.py:331:  Executing command: ['fedpkg', 'sources'] with env
 {'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash',
 'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'echo -n mock-chroot', 'HOME':
 '/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin'}
 DEBUG util.py:281:  ==15737==AddressSanitizer CHECK failed: 
 ../../../../libsanitizer/asan/asan_globals.cc:91 
 ((AddrIsAlignedByGranularity(g-beg))) != (0) (0x0, 0x0)
 DEBUG util.py:281:  #0 0xb583d21b (/lib/libasan.so.1+0x6121b)
 DEBUG util.py:281:  #1 0xb5841a8b in __sanitizer::CheckFailed(char 
 const*, int, char const*, unsigned long long, unsigned long long) 
 (/lib/libasan.so.1+0x65a8b)
 DEBUG util.py:281:  #2 0xb57fb01b in __asan_register_globals 
 (/lib/libasan.so.1+0x1f01b)
 DEBUG util.py:281:  #3 0xb6f14877 in call_init.part.0 
 (/lib/ld-linux-armhf.so.3+0x11877)
 DEBUG util.py:281:  #4 0xb6f149d3 in _dl_init 
 (/lib/ld-linux-armhf.so.3+0x119d3)
 DEBUG util.py:281:  #5 0xb6f199e7 in dl_open_worker 
 (/lib/ld-linux-armhf.so.3+0x169e7)
 DEBUG util.py:281:  #6 0xb6f14723 in _dl_catch_error 
 (/lib/ld-linux-armhf.so.3+0x11723)
 DEBUG util.py:281:  #7 0xb6f18f3f in _dl_open 
 (/lib/ld-linux-armhf.so.3+0x15f3f)
 DEBUG util.py:281:  #8 0xb6d58d03 in dlopen_doit (/lib/libdl.so.2+0xd03)
 DEBUG util.py:281:  #9 0xb6f14723 in _dl_catch_error 
 (/lib/ld-linux-armhf.so.3+0x11723)
 DEBUG util.py:281:  #10 0xb6d594c7 in _dlerror_run 
 (/lib/libdl.so.2+0x14c7)
 DEBUG util.py:281:  #11 0xb6d58dcf in __dlopen (/lib/libdl.so.2+0xdcf)
 DEBUG util.py:281:  #12 0xb6e8055f in _PyImport_GetDynLoadFunc 
 (/lib/libpython2.7.so.1.0+0xfa55f)
 DEBUG util.py:281:  #13 0xb6e6803b in _PyImport_LoadDynamicModule 
 (/lib/libpython2.7.so.1.0+0xe203b)
 DEBUG util.py:281:  #14 0xb6e65e7f (/lib/libpython2.7.so.1.0+0xdfe7f)
 DEBUG util.py:281:  #15 0xb6e660d3 (/lib/libpython2.7.so.1.0+0xe00d3)
 DEBUG util.py:281:  #16 0xb6e66bab in PyImport_ImportModuleLevel 
 (/lib/libpython2.7.so.1.0+0xe0bab)
 DEBUG util.py:281:  #17 0xb6e4adf3 (/lib/libpython2.7.so.1.0+0xc4df3)
 DEBUG util.py:281:  #18 0xb6def51b in PyCFunction_Call 
 (/lib/libpython2.7.so.1.0+0x6951b)
 DEBUG util.py:281:  #19 0xb6db1d6f in PyObject_Call 
 (/lib/libpython2.7.so.1.0+0x2bd6f)
 DEBUG util.py:281:  #20 0xb6e4ceab in PyEval_CallObjectWithKeywords 
 (/lib/libpython2.7.so.1.0+0xc6eab)
 DEBUG util.py:281:  #21 0xb6e4fb63 in PyEval_EvalFrameEx 
 (/lib/libpython2.7.so.1.0+0xc9b63)
 DEBUG util.py:281:  #22 0xb6e53c3f in PyEval_EvalCodeEx 
 (/lib/libpython2.7.so.1.0+0xcdc3f)
 DEBUG util.py:281:  #23 0xb6e53e03 in PyEval_EvalCode 
 (/lib/libpython2.7.so.1.0+0xcde03)
 DEBUG util.py:281:  #24 0xb6e64e93 in PyImport_ExecCodeModuleEx 
 (/lib/libpython2.7.so.1.0+0xdee93)
 DEBUG util.py:281:  #25 0xb6e6511b (/lib/libpython2.7.so.1.0+0xdf11b)
 DEBUG util.py:281:  #26 0xb6e666b7 (/lib/libpython2.7.so.1.0+0xe06b7)
 DEBUG util.py:281:  #27 0xb6e65e7f (/lib/libpython2.7.so.1.0+0xdfe7f)
 DEBUG util.py:281:  #28 0xb6e6612b (/lib/libpython2.7.so.1.0+0xe012b)
 DEBUG util.py:281:  #29 0xb6e66b5f in PyImport_ImportModuleLevel 
 (/lib/libpython2.7.so.1.0+0xe0b5f)
 DEBUG util.py:281:  #30 0xb6e4adf3 (/lib/libpython2.7.so.1.0+0xc4df3)
 DEBUG util.py:281:  #31 0xb6def51b in PyCFunction_Call 
 (/lib/libpython2.7.so.1.0+0x6951b)
 DEBUG util.py:281:  #32 0xb6db1d6f in PyObject_Call 
 (/lib/libpython2.7.so.1.0+0x2bd6f)
 DEBUG util.py:281:  #33 0xb6e4ceab in PyEval_CallObjectWithKeywords 
 (/lib/libpython2.7.so.1.0+0xc6eab)
 DEBUG util.py:281:  #34 0xb6e4fb63 in PyEval_EvalFrameEx 
 (/lib/libpython2.7.so.1.0+0xc9b63)
 DEBUG util.py:281:  #35 0xb6e53c3f in PyEval_EvalCodeEx 
 (/lib/libpython2.7.so.1.0+0xcdc3f)
 DEBUG util.py:281:  #36 0xb6e53e03 in PyEval_EvalCode 
 (/lib/libpython2.7.so.1.0+0xcde03)
 DEBUG util.py:281:  #37 0xb6e64e93 in PyImport_ExecCodeModuleEx 
 (/lib/libpython2.7.so.1.0+0xdee93)
 DEBUG util.py:281:  #38 0xb6e6511b (/lib/libpython2.7.so.1.0+0xdf11b)
 DEBUG

Re: F21 system GCC changed to 4.9.0 prerelease

2014-04-10 Thread Josh Boyer 
On Thu, Apr 10, 2014 at 6:23 AM, Jakub Jelinek ja...@redhat.com wrote:
 Hi!

 FYI, gcc in rawhide has been upgraded to 4.9.0 prerelease,
 please visit http://gcc.gnu.org/gcc-4.9/porting_to.html if your
 package no longer builds.  To investigate runtime rather than compile time
 issues, please consider using temporarily -fsanitize=undefined and/or
 -fsanitize=address to look for undefined behavior in the packages
 you own.

Hm.  So the kernel I tried to build this morning failed on ARM:

http://koji.fedoraproject.org/koji/getfile?taskID=6723963name=build.log

That cross-built locally (gcc 4.8.1) here fine before I sent it to
koji.  Anyone have any ideas on that?

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 system GCC changed to 4.9.0 prerelease

2014-04-10 Thread Jóhann B. Guðmundsson 


On 04/10/2014 02:06 PM, Josh Boyer wrote:

On Thu, Apr 10, 2014 at 6:23 AM, Jakub Jelinek ja...@redhat.com wrote:

Hi!

FYI, gcc in rawhide has been upgraded to 4.9.0 prerelease,
please visit http://gcc.gnu.org/gcc-4.9/porting_to.html if your
package no longer builds.  To investigate runtime rather than compile time
issues, please consider using temporarily -fsanitize=undefined and/or
-fsanitize=address to look for undefined behavior in the packages
you own.

Hm.  So the kernel I tried to build this morning failed on ARM:

http://koji.fedoraproject.org/koji/getfile?taskID=6723963name=build.log

That cross-built locally (gcc 4.8.1) here fine before I sent it to
koji.  Anyone have any ideas on that?

Could be this [1]

JBG

1. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60663

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 system GCC changed to 4.9.0 prerelease

2014-04-10 Thread Richard W.M. Jones 
On Thu, Apr 10, 2014 at 12:23:07PM +0200, Jakub Jelinek wrote:
 To investigate runtime rather than compile time
 issues, please consider using temporarily -fsanitize=undefined and/or
 -fsanitize=address to look for undefined behavior in the packages
 you own.

Which is this in case anyone else was wondering:

  '-fsanitize=address'
 Enable AddressSanitizer, a fast memory error detector.  Memory
 access instructions will be instrumented to detect out-of-bounds
 and use-after-free bugs.  See
 http://code.google.com/p/address-sanitizer/ for more details.
 The run-time behavior can be influenced using the 'ASAN_OPTIONS'
 environment variable; see
 https://code.google.com/p/address-sanitizer/wiki/Flags#Run-time_flags
 for a list of supported options.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 system GCC changed to 4.9.0 prerelease

2014-04-10 Thread Josh Boyer 
On Thu, Apr 10, 2014 at 10:06 AM, Josh Boyer jwbo...@fedoraproject.org wrote:
 On Thu, Apr 10, 2014 at 6:23 AM, Jakub Jelinek ja...@redhat.com wrote:
 Hi!

 FYI, gcc in rawhide has been upgraded to 4.9.0 prerelease,
 please visit http://gcc.gnu.org/gcc-4.9/porting_to.html if your
 package no longer builds.  To investigate runtime rather than compile time
 issues, please consider using temporarily -fsanitize=undefined and/or
 -fsanitize=address to look for undefined behavior in the packages
 you own.

 Hm.  So the kernel I tried to build this morning failed on ARM:

 http://koji.fedoraproject.org/koji/getfile?taskID=6723963name=build.log

 That cross-built locally (gcc 4.8.1) here fine before I sent it to
 koji.  Anyone have any ideas on that?

An f20 scratch build of the same SRPM has progressed past the failure
point above.  I suppose I'll dig into what changed in this regard and
see if there's a fix that works for both.  In the meantime, if anyone
knows what might have changed in gcc 4.9 to cause this, please speak
up.

http://koji.fedoraproject.org/koji/taskinfo?taskID=6724145

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 system GCC changed to 4.9.0 prerelease

2014-04-10 Thread Josh Boyer 
On Thu, Apr 10, 2014 at 10:15 AM, Jóhann B. Guðmundsson
johan...@gmail.com wrote:

 On 04/10/2014 02:06 PM, Josh Boyer wrote:

 On Thu, Apr 10, 2014 at 6:23 AM, Jakub Jelinek ja...@redhat.com wrote:

 Hi!

 FYI, gcc in rawhide has been upgraded to 4.9.0 prerelease,
 please visit http://gcc.gnu.org/gcc-4.9/porting_to.html if your
 package no longer builds.  To investigate runtime rather than compile
 time
 issues, please consider using temporarily -fsanitize=undefined and/or
 -fsanitize=address to look for undefined behavior in the packages
 you own.

 Hm.  So the kernel I tried to build this morning failed on ARM:

 http://koji.fedoraproject.org/koji/getfile?taskID=6723963name=build.log

 That cross-built locally (gcc 4.8.1) here fine before I sent it to
 koji.  Anyone have any ideas on that?

 Could be this [1]

 JBG

 1. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60663

Indeed.  I just found that myself.  Thanks.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 system GCC changed to 4.9.0 prerelease

2014-04-10 Thread Orion Poplawski 
On 04/10/2014 04:23 AM, Jakub Jelinek wrote:
 Hi!
 
 FYI, gcc in rawhide has been upgraded to 4.9.0 prerelease,
 please visit http://gcc.gnu.org/gcc-4.9/porting_to.html if your
 package no longer builds.  To investigate runtime rather than compile time
 issues, please consider using temporarily -fsanitize=undefined and/or
 -fsanitize=address to look for undefined behavior in the packages
 you own.
 
   Jakub
 

I think I've found a regression in gfortran with list-directed reading
from character arrays: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60810
unless this is some kind of new standards compliance, but this seems to
have worked forever.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 system GCC changed to 4.9.0 prerelease

2014-04-10 Thread Josh Boyer 
On Thu, Apr 10, 2014 at 11:01 AM, Josh Boyer jwbo...@fedoraproject.org wrote:
 On Thu, Apr 10, 2014 at 10:15 AM, Jóhann B. Guðmundsson
 johan...@gmail.com wrote:

 On 04/10/2014 02:06 PM, Josh Boyer wrote:

 On Thu, Apr 10, 2014 at 6:23 AM, Jakub Jelinek ja...@redhat.com wrote:

 Hi!

 FYI, gcc in rawhide has been upgraded to 4.9.0 prerelease,
 please visit http://gcc.gnu.org/gcc-4.9/porting_to.html if your
 package no longer builds.  To investigate runtime rather than compile
 time
 issues, please consider using temporarily -fsanitize=undefined and/or
 -fsanitize=address to look for undefined behavior in the packages
 you own.

 Hm.  So the kernel I tried to build this morning failed on ARM:

 http://koji.fedoraproject.org/koji/getfile?taskID=6723963name=build.log

 That cross-built locally (gcc 4.8.1) here fine before I sent it to
 koji.  Anyone have any ideas on that?

 Could be this [1]

 JBG

 1. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60663

 Indeed.  I just found that myself.  Thanks.

On the bright side, a scratch build with just i686 and x86_64 does build fine:

http://koji.fedoraproject.org/koji/taskinfo?taskID=6724931

So the issue seems isolated to ARM.  At least in terms of building.
Haven't tested functionality yet.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 system GCC changed to 4.9.0 prerelease

2014-04-10 Thread Corey Sheldon 
how stable is the x86 4.9 prerelease?
when building I mean


Corey W Sheldon
Owner, 1st Class Mobile Shine
310.909.7672
www.facebook.com/1stclassmobileshine


On Thu, Apr 10, 2014 at 2:05 PM, Josh Boyer jwbo...@fedoraproject.orgwrote:

 On Thu, Apr 10, 2014 at 11:01 AM, Josh Boyer jwbo...@fedoraproject.org
 wrote:
  On Thu, Apr 10, 2014 at 10:15 AM, Jóhann B. Guðmundsson
  johan...@gmail.com wrote:
 
  On 04/10/2014 02:06 PM, Josh Boyer wrote:
 
  On Thu, Apr 10, 2014 at 6:23 AM, Jakub Jelinek ja...@redhat.com
 wrote:
 
  Hi!
 
  FYI, gcc in rawhide has been upgraded to 4.9.0 prerelease,
  please visit http://gcc.gnu.org/gcc-4.9/porting_to.html if your
  package no longer builds.  To investigate runtime rather than compile
  time
  issues, please consider using temporarily -fsanitize=undefined and/or
  -fsanitize=address to look for undefined behavior in the packages
  you own.
 
  Hm.  So the kernel I tried to build this morning failed on ARM:
 
 
 http://koji.fedoraproject.org/koji/getfile?taskID=6723963name=build.log
 
  That cross-built locally (gcc 4.8.1) here fine before I sent it to
  koji.  Anyone have any ideas on that?
 
  Could be this [1]
 
  JBG
 
  1. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60663
 
  Indeed.  I just found that myself.  Thanks.

 On the bright side, a scratch build with just i686 and x86_64 does build
 fine:

 http://koji.fedoraproject.org/koji/taskinfo?taskID=6724931

 So the issue seems isolated to ARM.  At least in terms of building.
 Haven't tested functionality yet.

 josh
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 system GCC changed to 4.9.0 prerelease

2014-04-10 Thread Josh Boyer 
On Thu, Apr 10, 2014 at 2:09 PM, Corey Sheldon sheldon.co...@gmail.com wrote:
 how stable is the x86 4.9 prerelease?
 when building I mean

Well... it built a kernel.  It possibly built other packages in koji
in the meantime.  Other than that, I have no idea.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct