Find the answer to your Linux question:
Results 1 to 4 of 4
actually i m working on Firewall and Socket programming and i m receiving segmentation fault at a particular point in my code. actually my reads from a socket and the ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Apr 2004
    Location
    india
    Posts
    2

    Segmentation fault


    actually i m working on Firewall and Socket programming and i m receiving segmentation fault at a particular point in my code.

    actually my reads from a socket and the server side program excutes excatly well for the first three times and the fourth time it gives SIGSEGV segmentation fault at a particular line.

    char * ele_tag = (char*) malloc(len +5);

    where len is never larger than 50
    i m also frreing the mamory each time i come out of the function containing this code.

    free(ele_tag);

    if there is any problem with the code then why does it executes for the first three times.

    please help

  2. #2
    Linux Guru
    Join Date
    Apr 2003
    Location
    London, UK
    Posts
    3,284
    Without having ALL the code to your program, and the same system as you, it is impossible for us to say "oh, x is the problem, change y and it will work".

    Spend some time investigating how to use GDB (a debugger) & DDD - the graphical frontend for GDB.

    Jason

  3. #3
    don
    don is offline
    Linux Newbie
    Join Date
    Apr 2004
    Posts
    101
    just for debugging purposes.. couldnt you try al alternate memory allocation like an array where you can set your maximum size as its index. you could even try a linked list for better memory allocation.
    I\'m just a simple fisherman blessed with a lot of friends

  4. $spacer_open
    $spacer_close
  5. #4
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578
    If your program SIGSEGVs on malloc, it is most likely that you're doing some core fandango (aka fence breaking, heap corruption, etc.). These are the hardest kinds of errors to debug, since you never know where the error is first caused.

    The idea is that you make a mistake at some place in your code and accidently overwrite some internal malloc structures. These corruptions can then lie dormant for many, many cycles, until malloc needs them again and crashes (or accidently survives, but in turn corrupts something else that later makes your program crash). It most often that you allocate one byte less than needed (like ignoring storage for the NUL byte in the end of strings), and then overwrite the fence structure (the fence structures are the structures that malloc places between chunks).

    I've spent 10+ hours straight trying to remove errors like this from my own programs, even with relatively small programs (~2000 lines). You basically need to step through every line and see where you're committing the error. You better know gdb and assembly... =/ I am extremely thankful that I don't do such things very often anymore.

    If anything, you can try valgrind. Valgrind is an _excellent_ debugging program. It emulates an x86 CPU and warns you when your program does something that seems strange. Valgrind cannot catch everything, but if it does, it can save you many hours of tedious debugging for these kinds of problems.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •