Thread: Why is this a seg fault?

  1. #1
    Registered User
    Join Date
    Jun 2010
    Posts
    4

    Why is this a seg fault?

    Code:
    int CalcIt(char* a, int m)
    {
    char* aCopy = malloc(sizeof(char*)*1000*m);
    strcpy(aCopy,a);
    
    return 0;
    }
    }
    This is part of a bigger program and I am only getting a seg fault here on large iterations.

    Why does this seg fault on strcpy?

    Thanks
    -Jeff

  2. #2
    Gawking at stupidity
    Join Date
    Jul 2004
    Location
    Oregon, USA
    Posts
    3,218
    Well how long is the string a?

    Also, you don't want to use sizeof(char *) in your calculation... and where did you get 1000? What the hell is m supposed to be? We're not mind readers and your variables names suck the big one as far as descriptiveness is concerned. Help us help you.
    If you understand what you're doing, you're not learning anything.

  3. #3
    Registered User
    Join Date
    May 2010
    Location
    Naypyidaw
    Posts
    1,314
    Code:
    char* aCopy = malloc(sizeof(char )*1000*m);   // sizeof(char) not char*
    Prefer way:

    Code:
    T *p = malloc( sizeof(*p) );
    Make sure a is proper C string. and m > 0.
    And obvious malloc() return NULL Duh~

    Edit: heap overflow is possible too. if len(a) > allocated_len(acopy)
    Last edited by Bayint Naung; 04-08-2011 at 03:30 PM.

  4. #4
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    Well given your inability to use malloc correctly for just making a copy of a string, I'd say you've screwed up on some other malloc call elsewhere in your "bigger program".

    If you do this, anywhere, at any time, with any kind of pointer (this is just an example with strings)
    char *p = malloc(10);
    strcpy(p, "oops, this is too long to fit in 10 bytes");

    Then you might observe one or more of the following
    - absolutely nothing unusual, program works as expected
    - program crashes on exit
    - program crashes immediately
    - program crashes on the next malloc
    - program crashes on the next free
    - program crashes on some random future malloc/free
    - program crashes on some access of allocated memory
    - program crashes on ....
    Well, you get the idea.

    Trashed memory pools are like minefields. The damage has been done, it's only a question of how long before you find out.

    One thing is for sure, staring at the crash site is seldom productive. Chances are, the problem really occurred at some point in the past.

    Finding the real problem is a challenge, but help is at hand if you're on Linux (Windows users have to hand over lots of $$$ to get something similar).
    Code:
    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>
    
    void foo ( void ) {
      char *p = malloc(10);
      strcpy(p, "oops, this is too long to fit in 10 bytes");
    }
    int main(void)
    {
      foo();
      printf("OK so far...\n");
      return 0;
    }
    
    
    $ gcc -g bar.c
    $ ./a.out 
    OK so far...
    $ valgrind ./a.out
    ==2377== Memcheck, a memory error detector
    ==2377== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
    ==2377== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
    ==2377== Command: ./a.out
    ==2377== 
    ==2377== Invalid write of size 1
    ==2377==    at 0x4026975: memcpy (mc_replace_strmem.c:497)
    ==2377==    by 0x8048484: foo (bar.c:7)
    ==2377==    by 0x8048494: main (bar.c:11)
    ==2377==  Address 0x4199032 is 0 bytes after a block of size 10 alloc'd
    ==2377==    at 0x4024F20: malloc (vg_replace_malloc.c:236)
    ==2377==    by 0x8048465: foo (bar.c:6)
    ==2377==    by 0x8048494: main (bar.c:11)
    ==2377== 
    ==2377== Invalid write of size 1
    ==2377==    at 0x402697E: memcpy (mc_replace_strmem.c:497)
    ==2377==    by 0x8048484: foo (bar.c:7)
    ==2377==    by 0x8048494: main (bar.c:11)
    ==2377==  Address 0x4199033 is 1 bytes after a block of size 10 alloc'd
    ==2377==    at 0x4024F20: malloc (vg_replace_malloc.c:236)
    ==2377==    by 0x8048465: foo (bar.c:6)
    ==2377==    by 0x8048494: main (bar.c:11)
    ==2377== 
    ==2377== Invalid write of size 1
    ==2377==    at 0x4026964: memcpy (mc_replace_strmem.c:497)
    ==2377==    by 0x8048484: foo (bar.c:7)
    ==2377==    by 0x8048494: main (bar.c:11)
    ==2377==  Address 0x4199034 is 2 bytes after a block of size 10 alloc'd
    ==2377==    at 0x4024F20: malloc (vg_replace_malloc.c:236)
    ==2377==    by 0x8048465: foo (bar.c:6)
    ==2377==    by 0x8048494: main (bar.c:11)
    ==2377== 
    ==2377== Invalid write of size 1
    ==2377==    at 0x402696C: memcpy (mc_replace_strmem.c:497)
    ==2377==    by 0x8048484: foo (bar.c:7)
    ==2377==    by 0x8048494: main (bar.c:11)
    ==2377==  Address 0x4199035 is 3 bytes after a block of size 10 alloc'd
    ==2377==    at 0x4024F20: malloc (vg_replace_malloc.c:236)
    ==2377==    by 0x8048465: foo (bar.c:6)
    ==2377==    by 0x8048494: main (bar.c:11)
    ==2377== 
    ==2377== Invalid write of size 1
    ==2377==    at 0x40269B4: memcpy (mc_replace_strmem.c:497)
    ==2377==    by 0x8048484: foo (bar.c:7)
    ==2377==    by 0x8048494: main (bar.c:11)
    ==2377==  Address 0x4199050 is not stack'd, malloc'd or (recently) free'd
    ==2377== 
    OK so far...
    ==2377== 
    ==2377== HEAP SUMMARY:
    ==2377==     in use at exit: 10 bytes in 1 blocks
    ==2377==   total heap usage: 1 allocs, 0 frees, 10 bytes allocated
    ==2377== 
    ==2377== LEAK SUMMARY:
    ==2377==    definitely lost: 10 bytes in 1 blocks
    ==2377==    indirectly lost: 0 bytes in 0 blocks
    ==2377==      possibly lost: 0 bytes in 0 blocks
    ==2377==    still reachable: 0 bytes in 0 blocks
    ==2377==         suppressed: 0 bytes in 0 blocks
    ==2377== Rerun with --leak-check=full to see details of leaked memory
    ==2377== 
    ==2377== For counts of detected and suppressed errors, rerun with: -v
    ==2377== ERROR SUMMARY: 32 errors from 5 contexts (suppressed: 13 from 8)
    The red block is the call stack showing you where the illegal memory reference happened.
    The blue block is the call stack to where that memory was allocated.
    Follow each one, and decide whether to allocate more memory, or write less data.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Getting a seg fault
    By ammochck21 in forum C Programming
    Replies: 11
    Last Post: 01-23-2009, 05:27 AM
  2. Seg Fault in Compare Function
    By tytelizgal in forum C Programming
    Replies: 1
    Last Post: 10-25-2008, 03:06 PM
  3. seg fault at vectornew
    By tytelizgal in forum C Programming
    Replies: 2
    Last Post: 10-25-2008, 01:22 PM
  4. weird seg fault
    By Vermelho in forum C Programming
    Replies: 3
    Last Post: 05-10-2008, 08:27 PM
  5. Seg Fault Problem
    By ChazWest in forum C++ Programming
    Replies: 2
    Last Post: 04-18-2002, 03:24 PM