public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Nathan Boley <npboley@gmail.com>
To: gcc@gcc.gnu.org
Subject: Possible Bug
Date: Sat, 26 Mar 2011 20:28:00 -0000	[thread overview]
Message-ID: <AANLkTinhFkPH4+0wzV+gGGf-CJNTnOi5MQ1-bQgJJkPK@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1748 bytes --]

Hi All,

In a much larger application, I was getting a weird segfault that an
assignment to a temporary variable fixed. I distilled the example into
the attached "test_case.c". When I run test_case.c under valgrind I
get a memory read error, and it segfaults with electric fence, but I'm
not actually able to get a true segfault. However, I am pretty sure
that the same issue was causing the segfault in my application.

From my really limited assembly knowledge, it looks that on 64 bit
machines gcc is trying to do a full 8 byte read into the register
followed by a 2 byte shift ( instead of 4 then 2 byte read ). If the
two extra bytes are out of bounds it will segfault. This explains why
I get the sporadic segfaults in my bigger application ( where I can
actually be at the page boundary ), but not in the test case.

This only occurs on 64 bit machines, and my gcc version info is:

nboley@ingvas:~/Desktop$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.4.4-14ubuntu5'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-objc-gc --disable-werror
--with-arch-32=i686 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)

Best,
Nathan Boley

[-- Attachment #2: test_case.c --]
[-- Type: text/x-csrc, Size: 1025 bytes --]

#include <stdio.h>
#include <stdlib.h>

/* Does NOT cause memory error */
typedef struct __attribute__((__packed__))
{
   unsigned short chr;
   unsigned int loc;
} GENOME_LOC_TYPE_2;

/* Causes memory error */
typedef struct __attribute__((__packed__))
{
   unsigned chr            :16;
   unsigned loc            :32;
} GENOME_LOC_TYPE;

void
print_mapped_location( GENOME_LOC_TYPE loc )
{
   printf( "%i\n", loc.loc );
}

int main( int argc, char* argv )
{
   char* data;
   data = malloc(12*sizeof(char));

   GENOME_LOC_TYPE* gen_array
       = (GENOME_LOC_TYPE*) data;
   gen_array[0].loc = 0;
   gen_array[1].loc = 1;

   /* Make sure the structure is actually 6 bytes */
   printf("Gen Loc Type Size: %zu\n", sizeof(GENOME_LOC_TYPE) );

   /* Works fine. */
   printf( "%i\n", gen_array[1].loc );

   /* Works fine */
   GENOME_LOC_TYPE loc = gen_array[1];
   print_mapped_location( loc );

   /* Causes valgrind error */
   /* Cause -lefence segfault */
   print_mapped_location( gen_array[1] );

   free( data );
}

             reply	other threads:[~2011-03-26 20:04 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-26 20:28 Nathan Boley [this message]
2011-03-27  7:38 ` Ian Lance Taylor
2011-03-28 11:06   ` Paolo Bonzini
2011-03-28 11:28     ` Richard Guenther
2011-03-28 11:47       ` Paolo Bonzini
2011-03-28 12:14         ` Richard Guenther
2011-03-28 13:37         ` Michael Matz
2011-03-28 13:54           ` Paolo Bonzini
2011-03-28 14:37             ` Richard Guenther
2011-03-29 16:03               ` Nathan Boley
  -- strict thread matches above, loose matches on Subject: below --
2003-01-31  0:33 possible bug Andrew Morton
2003-01-31  0:36 ` Jan Hubicka
2003-01-31  0:56   ` Andrew Morton
2003-01-31  8:08   ` Alexandre Oliva
2003-01-31 10:48     ` Fergus Henderson
1999-07-25 17:52 Manush Dodunekov
1999-07-26 10:57 ` Alexandre Oliva
1999-07-27  3:27   ` Manush Dodunekov
1999-07-27  3:37     ` Alexandre Oliva
1999-07-31 23:33       ` Alexandre Oliva
1999-07-31 23:33     ` Manush Dodunekov
1999-07-31 23:33   ` Alexandre Oliva
1999-07-31 23:33 ` Manush Dodunekov
1997-12-12 15:46 Possible Bug Mike Sullivan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTinhFkPH4+0wzV+gGGf-CJNTnOi5MQ1-bQgJJkPK@mail.gmail.com \
    --to=npboley@gmail.com \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).