segmentation fault when invoking new

This is a discussion on segmentation fault when invoking new within the C++ Programming forums, part of the General Programming Boards category; Hello everyone, When executing the following statement, -------------------- bool* a = new bool[8]; -------------------- There is a segmentation fault error, ...

  1. #1
    Registered User
    Join Date
    May 2006
    Posts
    1,579

    segmentation fault when invoking new

    Hello everyone,


    When executing the following statement,

    --------------------
    bool* a = new bool[8];
    --------------------

    There is a segmentation fault error,

    --------------------
    Program received signal SIGSEGV, Segmentation fault.
    [Switching to Thread 1075405984 (LWP 5495)]
    0x4207414b in _int_malloc () from /lib/tls/libc.so.6
    --------------------

    Does anyone have any ideas?


    regards,
    George
    Last edited by George2; 05-12-2006 at 05:06 AM.

  2. #2
    Registered User
    Join Date
    Aug 2005
    Posts
    1,267
    my guess is that the problem is somewhere else in your program -- it has probably trashed memory by using uninitialized pointers or buffer overruns.

  3. #3
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Hi Ancient


    Quote Originally Posted by Ancient Dragon
    my guess is that the problem is somewhere else in your program -- it has probably trashed memory by using uninitialized pointers or buffer overruns.
    Suppose there exists uninitialized pointers or buffer overruns, how can they affect the situation I am meeting with? Could you show me an example please?


    regards,
    George

  4. #4
    Registered User
    Join Date
    May 2006
    Location
    Troy
    Posts
    14
    the 'new' operator doesn't pull memory out of its hat, it looks through the array of memory, which is demarcated by some datastructures, and finds a place to put things. If you write to the wrong spot of memory, you'll mess up one of the markers that manage the heap, and the next time you try to use 'new', you'll get shot off to some invalid address because some marker's got some incorrect value.

  5. #5
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,592
    > Could you show me an example please?
    Question about malloc()
    Try using efence to see if it crashes before you attempt to new your bool array.
    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.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  6. #6
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thank you Rash,


    Quote Originally Posted by Rash
    the 'new' operator doesn't pull memory out of its hat, it looks through the array of memory, which is demarcated by some datastructures, and finds a place to put things. If you write to the wrong spot of memory, you'll mess up one of the markers that manage the heap, and the next time you try to use 'new', you'll get shot off to some invalid address because some marker's got some incorrect value.
    I understand your points now. Any ideas to solve this problem?


    regards,
    George

  7. #7
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thank you Salem,


    Quote Originally Posted by Salem
    > Could you show me an example please?
    Question about malloc()
    Try using efence to see if it crashes before you attempt to new your bool array.
    I have looked through this discussion, but I can not find any special benefits efence will offer. Would you point out please?


    regards,
    George

  8. #8
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,592
    > but I can not find any special benefits efence will offer. Would you point out please?
    Did you just assume that it can't. or did you try it?

    Your problem is 99% likely due to some problem you have using memory obtained by a previous call to new.
    Say for example, running off the end of allocated memory (which that link I posted is all about).

    efence traps the point at which the overrun occurs (in that case, strcpy), not at some random point in the future (in your case, a call to new)
    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.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  9. #9
    Registered User
    Join Date
    Mar 2006
    Posts
    725
    Can you check if the error is actually produced by that line? Can you post some debugging info? Can you post the 10-or-so lines before and after that line?
    Code:
    #include <stdio.h>
    
    void J(char*a){int f,i=0,c='1';for(;a[i]!='0';++i)if(i==81){
    puts(a);return;}for(;c<='9';++c){for(f=0;f<9;++f)if(a[i-i%27+i%9
    /3*3+f/3*9+f%3]==c||a[i%9+f*9]==c||a[i-i%9+f]==c)goto e;a[i]=c;J(a);a[i]
    ='0';e:;}}int main(int c,char**v){int t=0;if(c>1){for(;v[1][
    t];++t);if(t==81){J(v[1]);return 0;}}puts("sudoku [0-9]{81}");return 1;}

  10. #10
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Hi jafet,


    Quote Originally Posted by jafet
    Can you check if the error is actually produced by that line? Can you post some debugging info? Can you post the 10-or-so lines before and after that line?
    There is no line before that new statement line -- it is the first line of a method. And after the line, I just do some assignment of each elements of the array.

    The program crashed when executes the new statement -- I have used gdb to verify that.

    Any ideas of how to debug it?


    regards,
    George

  11. #11
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thank you Salem!


    Quote Originally Posted by Salem
    > but I can not find any special benefits efence will offer. Would you point out please?
    Did you just assume that it can't. or did you try it?
    Yes, I have tried it. But my program still crashed in the same way as before.

    Quote Originally Posted by Salem
    Your problem is 99% likely due to some problem you have using memory obtained by a previous call to new.
    Say for example, running off the end of allocated memory (which that link I posted is all about).
    I do not quite understand what do you mean "running off the end of allocated memory" in your sample. Could you provide sample codes please?

    Quote Originally Posted by Salem
    efence traps the point at which the overrun occurs (in that case, strcpy), not at some random point in the future (in your case, a call to new)
    What do you mean overrun? Means copy something out of bound or?


    regards,
    George

  12. #12
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,592
    How about posting ALL YOUR CODE then, providing it's not too large.

    Or at least a cut-down version of your program which complete, that is it crashes for you and we can at least just look at it, compile it and perhaps even see the same behaviour.

    One random line out of your code just isn't going to tell you or us anything.
    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.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  13. #13
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Hi Salem,


    Quote Originally Posted by Salem
    How about posting ALL YOUR CODE then, providing it's not too large.

    Or at least a cut-down version of your program which complete, that is it crashes for you and we can at least just look at it, compile it and perhaps even see the same behaviour.

    One random line out of your code just isn't going to tell you or us anything.
    The program is too large -- 10-20 source files. I am going to cut down something and try to re-produce the problem with a small program. Do you think it is the correct approach?


    regards,
    George

  14. #14
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,592
    I'm really surprised that electric fence doesn't show up the problem for you.

    > The program is too large -- 10-20 source files
    Yes, this is much too large for this forum.

    It seems pretty typical of most attempts to write large software for the first time, since many forms of dynamic memory abuse only really start to show up in large programs, and at the same time are exceedingly hard to track down without lots of tools.

    > I am going to cut down something and try to re-produce the problem with a small program.
    It's worth a shot, if the 'bool* a = new bool[8];' appears close to the start of the program.
    If the programs been running for a while before the problem hits, then replicating the problem could be just as hard as finding the cure.

    But remember, changing the code in any way could equally cause the problem to become hidden again, but not for any real reason which can be explained. This probably explains why the problem "magically" appeared in the first place.

    > What do you mean overrun? Means copy something out of bound or?
    Yes - like the strcpy() in the other thread demonstrates.

    Things you need to contend with are
    - using memory before you allocate it
    - using memory after you delete it
    - deleting the same thing twice
    - deleting something you never allocated
    - allocating to a pointer, then changing the pointer and deleting the changed pointer
    - allocating an array, and only deleting an instance (or vice-versa).
    Eg. p = new char[10]; ... delete p; // should have been delete [ ] p;
    - accessing memory which is off either end of the allocation.
    - mixing new/malloc and delete/free. Note in particular that malloc does NOT call constructors.

    > bool* a = new bool[8];
    Consider upgrading all your code to use the STL.
    The STL offers much safer memory use over do it yourself allocations.
    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.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. segmentation fault... first time with unix...
    By theMethod in forum C Programming
    Replies: 16
    Last Post: 09-30-2008, 02:01 AM
  2. Segmentation fault
    By bennyandthejets in forum C++ Programming
    Replies: 7
    Last Post: 09-07-2005, 05:04 PM
  3. Segmentation fault
    By NoUse in forum C Programming
    Replies: 4
    Last Post: 03-26-2005, 02:29 PM
  4. Locating A Segmentation Fault
    By Stack Overflow in forum C Programming
    Replies: 12
    Last Post: 12-14-2004, 12:33 PM
  5. Segmentation fault...
    By alvifarooq in forum C++ Programming
    Replies: 14
    Last Post: 09-26-2004, 12:53 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21