Segmentation fault in C code

The following code prints the message that I need it to print using the for loop and character array seen at the end of this code but a segmentation fault occurs after the loop is done and I cannot figure out what the cause is.

#include "bmp.h"

void extractMessage(BMPfile bmpfile) 
{
void extractMessage(BMPfile bmpfile) 
{
    short index = 0;
char word[16];
unsigned char letter = 0;
unsigned char count = 0;
unsigned char temp;
int width = getWidth(bmpfile);
int height = getHeight(bmpfile);
printf("The image has %d x %d pixels\n", width, height);
for (int y = 0 ; y < height ; y++) 
{
    for (int x = 0 ; x < width ; x++) 
    {
        pixel p = getPixel(bmpfile, x, y);  /* read pixel */        
        temp = p.green & 0x01;
        letter = letter << 1;
        letter = letter + temp;         
        count += 1;  
        if(count == 8){
            word[index] = letter;
            index += 1;
            count = 0;} 
        if  (letter == '0')
        {
            break;
        }   
    }
}
    for (int x=0; x < 16; x++)
    {
    printf("%c",word[x]);
    }
}

Additionally Valgrind gives the following information which I have no idea how to interpret.

Memcheck, a memory error detector
==13094== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==13094== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==13094== Command: ./p1 picture.bmp
==13094== 
The image has 450 x 683 pixels
==13094== Invalid write of size 1
==13094==    at 0x400845: extractMessage (in /home/hauger3/hauger3/cs398/Lab2/p1)
==13094==    by 0x400C72: main (in /home/hauger3/hauger3/cs398/Lab2/p1)
==13094==  Address 0x7ff001000 is not stack'd, malloc'd or (recently) free'd
==13094== 
==13094== 
==13094== Process terminating with default action of signal 11 (SIGSEGV)
==13094==  Access not within mapped region at address 0x7FF001000
==13094==    at 0x400845: extractMessage (in /home/hauger3/hauger3/cs398/Lab2/p1)
==13094==    by 0x400C72: main (in /home/hauger3/hauger3/cs398/Lab2/p1)
==13094==  If you believe this happened as a result of a stack
==13094==  overflow in your program's main thread (unlikely but
==13094==  possible), you can try to increase the size of the
==13094==  main thread stack using the --main-stacksize= flag.
==13094==  The main thread stack size used in this run was 10485760.
==13094== 
==13094== HEAP SUMMARY:
==13094==     in use at exit: 568 bytes in 1 blocks
==13094==   total heap usage: 1 allocs, 0 frees, 568 bytes allocated
==13094== 
==13094== LEAK SUMMARY:
==13094==    definitely lost: 0 bytes in 0 blocks
==13094==    indirectly lost: 0 bytes in 0 blocks
==13094==      possibly lost: 0 bytes in 0 blocks
==13094==    still reachable: 568 bytes in 1 blocks
==13094==         suppressed: 0 bytes in 0 blocks
==13094== Rerun with --leak-check=full to see details of leaked memory
==13094== 
==13094== For counts of detected and suppressed errors, rerun with: -v
==13094== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 6)
Segmentation fault
[hauger3@linux6 Lab2]$ valgrind --leak-check=full ./p1 picture.bmp 
==19793== Memcheck, a memory error detector
==19793== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==19793== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==19793== Command: ./p1 picture.bmp
==19793== 
The image has 450 x 683 pixels
==19793== Invalid write of size 1
==19793==    at 0x400845: extractMessage (in /home/hauger3/hauger3/cs398/Lab2/p1)
==19793==    by 0x400C72: main (in /home/hauger3/hauger3/cs398/Lab2/p1)
==19793==  Address 0x7ff001000 is not stack'd, malloc'd or (recently) free'd
==19793== 
==19793== 
==19793== Process terminating with default action of signal 11 (SIGSEGV)
==19793==  Access not within mapped region at address 0x7FF001000
==19793==    at 0x400845: extractMessage (in /home/hauger3/hauger3/cs398/Lab2/p1)
==19793==    by 0x400C72: main (in /home/hauger3/hauger3/cs398/Lab2/p1)
==19793==  If you believe this happened as a result of a stack
==19793==  overflow in your program's main thread (unlikely but
==19793==  possible), you can try to increase the size of the
==19793==  main thread stack using the --main-stacksize= flag.
==19793==  The main thread stack size used in this run was 10485760.
==19793== 
==19793== HEAP SUMMARY:
==19793==     in use at exit: 568 bytes in 1 blocks
==19793==   total heap usage: 1 allocs, 0 frees, 568 bytes allocated
==19793== 
==19793== LEAK SUMMARY:
==19793==    definitely lost: 0 bytes in 0 blocks
==19793==    indirectly lost: 0 bytes in 0 blocks
==19793==      possibly lost: 0 bytes in 0 blocks
==19793==    still reachable: 568 bytes in 1 blocks
==19793==         suppressed: 0 bytes in 0 blocks
==19793== Reachable blocks (those to which a pointer was found) are not shown.
==19793== To see them, rerun with: --leak-check=full --show-reachable=yes
==19793== 
==19793== For counts of detected and suppressed errors, rerun with: -v
==19793== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 6)
Segmentation fault

Answers


A segmentation fault occurs when you try to access memory that does not belong to your program. This typically happens by the following means:

  1. By dereferencing a pointer that points to a memory location that does not belong to your program. This can be a NULL pointer, a pointer whose associated memory has already been freed, or a pointer that is not initialized.
  2. By accessing an array element beyond the boundaries of the array.

Because you do not use any pointers, I suggest concentrating on the second item. Check whether the index is always >= 0 and < 16. An assert() before each access to the array will help you.


Need Your Help

Android - Multiple application names in manifest - Universal Image Loader and ACRA

android manifest universal-image-loader acra

so you know, I've been using ACRA for a while to allow users to send crash reports via email.

How to Execute AsyncTask in Android - erro in class Zygotelnit

java android android-asynctask

I have a Class extends AsyncTask that receive a Context, String user and String password,

About UNIX Resources Network

Original, collect and organize Developers related documents, information and materials, contains jQuery, Html, CSS, MySQL, .NET, ASP.NET, SQL, objective-c, iPhone, Ruby on Rails, C, SQL Server, Ruby, Arrays, Regex, ASP.NET MVC, WPF, XML, Ajax, DataBase, and so on.