Thread: Segmentation Fault

This program is a double-linked list in C for my System's Software class.
Everything worked fine, until I coded the delete() and insert() functions.

The program compiles and executes on a window machine using Dev C++.
It also compiles without any errors or warnings on a linux machine using
gcc -g scan.c P3.c

However, when executing the a.out file, the program crashes with a segmentation fault.
My TA and I tried to find the bug for hours today, but to no avail. I would appreciate any help. Thanks.

-Chris

I like when I look at the correct file the first time. P3.c has some nasty code in the delete() function. Basically the problem as far as I see it is that when you delete, you are functionally screwing up the chain. Also, you don't seem to deallocate anything at any point. If that is not of enough help just tell me so I can look more deeply at the code.

casting malloc is not needed in C.
You never free anything.
check the return values of malloc and fopen
check argc before you use argv.
compile with gcc -std=c99 -pedantic -Wall -Werror -Wextra -g scan.c P3.c
what is the input file?

I played around with the fixes, but no luck.

Thanks for the suggestions, but I believe there is more to the error then malloc or not deallocating memory. Since the program is small and doesn't run for long, I feel like it's more.

Are you on a linux machine?

The project requires that it work on a linux machine. Using gdb, I've narrowed the segmentation fault down to the delete function, but nothing seems to fix it. Anyone else have any ideas?

Looks like you ran out of memory? This malloc

Code:

struct Value *filler = (struct Value *)malloc(sizeof(struct Value));

returned NULL, and you didn't check for it.

valgrind results pending.

OK, valgrind results bear this out:

Code:

rags@riches:~> valgrind -v --leak-check=full --log-file=vgout.tx ./scan f.txt
rags@riches:~> less vgout.tx

==5515== Memcheck, a memory error detector.
==5515== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==5515== Using LibVEX rev 1804, a library for dynamic binary translation.
==5515== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==5515== Using valgrind-3.3.0, a dynamic binary instrumentation framework.
==5515== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==5515==
==5515== My PID = 5515, parent PID = 4322.  Prog and args are:
==5515==    ./scan
==5515==    f.txt
==5515==
--5515--
--5515-- Command line
--5515--    ./scan
--5515--    f.txt
--5515-- Startup, with flags:
--5515--    -v
--5515--    --leak-check=full
--5515--    --log-file=vgout.txt
--5515-- Contents of /proc/version:
--5515--   Linux version 2.6.16.46-0.12-bigsmp (geeko@buildhost) (gcc version 4.
1.2 20070115 (prerelease) (SUSE Linux)) #1 SMP Thu May 17 14:00:09 UTC 2007
--5515-- Arch and hwcaps: X86, x86-sse1-sse2
--5515-- Page sizes: currently 4096, max supported 4096
--5515-- Valgrind library directory: /usr/local/lib/valgrind
--5515-- Reading syms from /lib/ld-2.4.so (0x4000000)
--5515-- Reading syms from /home/rags/scan (0x8048000)
--5515-- Reading syms from /usr/local/lib/valgrind/x86-linux/memcheck (0x3800000
0)
--5515--    object doesn't have a dynamic symbol table
--5515-- Reading suppressions file: /usr/local/lib/valgrind/default.supp
--5515-- REDIR: 0x4014f00 (index) redirected to 0x3802ae53 (vgPlain_x86_linux_RE
DIR_FOR_index)
--5515-- Reading syms from /usr/local/lib/valgrind/x86-linux/vgpreload_core.so (
0x401D000)
--5515-- Reading syms from /usr/local/lib/valgrind/x86-linux/vgpreload_memcheck.
so (0x401F000)
==5515== WARNING: new redirection conflicts with existing -- ignoring it
--5515--     new: 0x04014f00 (index               ) R-> 0x04022630 index
--5515-- REDIR: 0x40150a0 (strlen) redirected to 0x40227e0 (strlen)
--5515-- Reading syms from /lib/libc-2.4.so (0x4039000)
--5515-- REDIR: 0x40a35c0 (rindex) redirected to 0x4022510 (rindex)
--5515-- REDIR: 0x40a0510 (malloc) redirected to 0x4021850 (malloc)
--5515-- REDIR: 0x40a2cf0 (strcpy) redirected to 0x4023b50 (strcpy)
==5515== Invalid write of size 1
==5515==    at 0x8049090: main (p3.c:180)
==5515==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==5515==
==5515== Process terminating with default action of signal 11 (SIGSEGV)
==5515==  Access not within mapped region at address 0x0
==5515==    at 0x8049090: main (p3.c:180)
--5515-- REDIR: 0x409e290 (free) redirected to 0x40213f0 (free)
--5515-- REDIR: 0x40a4440 (memset) redirected to 0x4022b40 (memset)
==5515==
==5515== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 3 from 1)
==5515==
==5515== 1 errors in context 1 of 1:
==5515== Invalid write of size 1
==5515==    at 0x8049090: main (p3.c:180)
==5515==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
--5515--
--5515-- supp:      3 Fedora-Core-5-hack3-ld24
==5515==
==5515== IN SUMMARY: 1 errors from 1 contexts (suppressed: 3 from 1)
==5515==
==5515== malloc/free: in use at exit: 1,580,440,456 bytes in 11,288,858 blocks.
==5515== malloc/free: 11,288,859 allocs, 0 frees, 1,580,440,456 bytes allocated.
==5515==
==5515==
    Valgrind's memory management: out of memory:
       newSuperblock's request for 45158400 bytes failed.
       3118125056 bytes have already been allocated.
    Valgrind cannot continue.  Sorry.

    There are several possible reasons for this.
    - You have some kind of memory limit in place.  Look at the
      output of 'ulimit -a'.  Is there a limit on the size of
      virtual memory or address space?
    - You have run out of swap space.
    - Valgrind has a bug.  If you think this is the case or you are
    not sure, please let us know and we'll try to fix it.
    Please note that programs can take substantially more memory than
    normal when running under Valgrind tools, eg. up to twice or
    more, depending on the tool.  On a 64-bit machine, Valgrind
    should be able to make use of up 32GB memory.  On a 32-bit
    machine, Valgrind should be able to use all the memory available
    to a single process, up to 4GB if that's how you have your
    kernel configured.  Most 32-bit Linux setups allow a maximum of
    3GB per process.

    Whatever the reason, Valgrind cannot continue.  Sorry.

It's obvious that your EOF condition is never getting hit. There are some strange characters at the end of f.txt; if I get rid of those, it works fine.

Thanks rags_to_riches. That sounds like a likely candidate for the error.
This is my first real program in C, so I'm learning as I go.