RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 865375 - segfaulting apps at startup on i686
Summary: segfaulting apps at startup on i686
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: glibc
Version: 6.4
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
: ---
Assignee: Jeff Law
QA Contact: qe-baseos-tools-bugs
URL:
Whiteboard:
Depends On:
Blocks: 846342
TreeView+ depends on / blocked
 
Reported: 2012-10-11 09:56 UTC by Dave Airlie
Modified: 2016-11-24 16:12 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
No documentation needed.
Clone Of:
Environment:
Last Closed: 2013-02-21 07:06:05 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0279 0 normal SHIPPED_LIVE glibc bug fix and enhancement update 2013-02-20 20:37:06 UTC

Description Dave Airlie 2012-10-11 09:56:10 UTC 
I've upgrade me 32-bit EL6 install to nightly, and I'm seeing a bunch of apps segfaulting at boot here,

cryptsetup, multipath, nmcli, NetworkManager, dmraid, pulseaudio, devkit-power-daemon

It only seems to happen on certain processors (the install is on a USB disk), if I had to guess I'd say SSSE3 processors and above, at least core 2 duo and i7.

Reading symbols from /usr/bin/nmcli...(no debugging symbols found)...done.
Missing separate debuginfos, use: debuginfo-install NetworkManager-0.8.1-37.el6.i686
(gdb) r
Starting program: /usr/bin/nmcli 

Program received signal SIGSEGV, Segmentation fault.
0x005ba6b8 in ?? ()
(gdb) bt
#0  0x005ba6b8 in ?? ()
#1  0x006083b8 in ?? ()
#2  0x001139ac in dl_main (phdr=0x8048034, phnum=8, user_entry=0xbffff75c, 
    auxv=0xbffff840) at rtld.c:2257
#3  0x00125a01 in _dl_sysdep_start (start_argptr=0xbffff7c0, 
    dl_main=0x112630 <dl_main>) at ../elf/dl-sysdep.c:244
#4  0x00111273 in _dl_start_final (arg=0xbffff7c0) at rtld.c:335
#5  _dl_start (arg=0xbffff7c0) at rtld.c:561
#6  0x00110857 in _start () from /lib/ld-linux.so.2

is a backtrace from nmcli.
Comment 1 Dave Airlie 2012-10-11 10:03:13 UTC 
downgrading to the latest EL6.3 package fixes it

glibc-2.12-1.80.el_6_3.5.i686
Comment 2 Dave Airlie 2012-10-11 10:13:20 UTC 
Also I see in the glibc changelog mention of a new env var

32BIT_SSSE3_MEMCPY_VIA_32BIT_SSSE3_MEMMOVE

but bash doesn't let you export env vars beginning with numbers for some reason, or at least it gives out when I do

export 32BIT_SSSE3_MEMCPY_VIA_32BIT_SSSE3_MEMMOVE=1
bash: export: `32BIT_SSSE3_MEMCPY_VIA_32BIT_SSSE3_MEMMOVE=1': not a valid identifier
Comment 3 Dave Airlie 2012-10-11 10:30:20 UTC 
my final contribution for now, valgrind trace of nmcli

I looked at glibc dist-git tree and saw the patch, but my 32-bit assembly is really bad at 8pm on a Thursday!

[root@dave6 ~]# valgrind nmcli
==5683== Memcheck, a memory error detector
==5683== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==5683== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==5683== Command: nmcli
==5683== 
==5683== Invalid read of size 4
==5683==    at 0x44D26B8: getenv (getenv.c:41)
==5683==    by 0x45203B7: memcpy (memcpy.S:57)
==5683==    by 0x400CE55: _dl_relocate_object (dl-machine.h:351)
==5683==    by 0x40039AB: dl_main (rtld.c:2257)
==5683==    by 0x4015A00: _dl_sysdep_start (dl-sysdep.c:244)
==5683==    by 0x4001272: _dl_start (rtld.c:335)
==5683==    by 0x4000856: ??? (in /lib/ld-2.12.so)
==5683==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==5683== 
==5683== 
==5683== Process terminating with default action of signal 11 (SIGSEGV)
==5683==  Access not within mapped region at address 0x0
==5683==    at 0x44D26B8: getenv (getenv.c:41)
==5683==    by 0x45203B7: memcpy (memcpy.S:57)
==5683==    by 0x400CE55: _dl_relocate_object (dl-machine.h:351)
==5683==    by 0x40039AB: dl_main (rtld.c:2257)
==5683==    by 0x4015A00: _dl_sysdep_start (dl-sysdep.c:244)
==5683==    by 0x4001272: _dl_start (rtld.c:335)
==5683==    by 0x4000856: ??? (in /lib/ld-2.12.so)
==5683==  If you believe this happened as a result of a stack
==5683==  overflow in your program's main thread (unlikely but
==5683==  possible), you can try to increase the size of the
==5683==  main thread stack using the --main-stacksize= flag.
==5683==  The main thread stack size used in this run was 10485760.
==5683== Jump to the invalid address stated on the next line
==5683==    at 0x32E: ???
==5683==    by 0x45F6797: ??? (in /lib/libc-2.12.so)
==5683==    by 0x45203B7: memcpy (memcpy.S:57)
==5683==    by 0x400CE55: _dl_relocate_object (dl-machine.h:351)
==5683==    by 0x40039AB: dl_main (rtld.c:2257)
==5683==    by 0x4015A00: _dl_sysdep_start (dl-sysdep.c:244)
==5683==    by 0x4001272: _dl_start (rtld.c:335)
==5683==    by 0x4000856: ??? (in /lib/ld-2.12.so)
==5683==  Address 0x32e is not stack'd, malloc'd or (recently) free'd
==5683== 
==5683== 
==5683== Process terminating with default action of signal 11 (SIGSEGV)
==5683==  Bad permissions for mapped region at address 0x32E
==5683==    at 0x32E: ???
==5683==    by 0x45F6797: ??? (in /lib/libc-2.12.so)
==5683==    by 0x45203B7: memcpy (memcpy.S:57)
==5683==    by 0x400CE55: _dl_relocate_object (dl-machine.h:351)
==5683==    by 0x40039AB: dl_main (rtld.c:2257)
==5683==    by 0x4015A00: _dl_sysdep_start (dl-sysdep.c:244)
==5683==    by 0x4001272: _dl_start (rtld.c:335)
==5683==    by 0x4000856: ??? (in /lib/ld-2.12.so)
==5683== 
==5683== HEAP SUMMARY:
==5683==     in use at exit: 0 bytes in 0 blocks
==5683==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==5683== 
==5683== All heap blocks were freed -- no leaks are possible
==5683== 
==5683== For counts of detected and suppressed errors, rerun with: -v
==5683== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Comment 4 Dave Airlie 2012-10-11 10:55:36 UTC 
add block on bug that caused this.
Comment 5 Jeff Law 2012-10-11 21:43:45 UTC 
It's definitely the insane hacks to work around broken applications which call memcpy with overlapping arguments.  I'm working on it.
Comment 8 errata-xmlrpc 2013-02-21 07:06:05 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0279.html
Note You need to log in before you can comment on or make changes to this bug.