What does this valgrind output mean, and how can I get it to display something that's understandable?

Question

I'm fairly new to C, and today I was introduced to Valgrind. I installed it and ran it on my C calculator/equation parser that I'm working on to figure out why I was having a segmentation fault (core dumped), and I got this:

==20== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==20==  General Protection Fault
==20==    at 0x4008E27: _dl_map_object (dl-load.c:2317)
==20==    by 0x40014DD: map_doit (rtld.c:642)
==20==    by 0x4010193: _dl_catch_error (dl-error.c:187)
==20==    by 0x4002169: do_preload (rtld.c:831)
==20==    by 0x4002169: handle_ld_preload (rtld.c:929)
==20==    by 0x4004DEE: dl_main (rtld.c:1667)
==20==    by 0x40176F4: _dl_sysdep_start (dl-sysdep.c:249)
==20==    by 0x4001BB7: _dl_start_final (rtld.c:347)
==20==    by 0x4001BB7: _dl_start (rtld.c:573)
==20==    by 0x4001267: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so)
==20==    by 0x1: ???
==20==    by 0x1FFF0008AE: ???
==20==    by 0x1FFF0008BB: ???

Of course, I have no idea what it means, and the other things I've found about similar errors haven't made much sense to me. Can someone explain this in a relatively simple way that someone like me can understand?

EDIT: I tried running it through gdb (ass suggested by @pm100), and only got this:

Program received signal SIGSEGV, Segmentation fault. 0x000000000040067b in ?? ()

EDIT: Since my code was asked for, here it is. I'm probably doing a lot wrong.

#include <stdlib.h>
#include <string.h>
#include <stdio.h>

void write(char** dest, char* src, int index) {
    int i = 0;
    for (i = 0; src[i] != '\0'; i++) {
        dest[index][i] = src[i];
    }
    dest[index][i] = '\0';
    return;
}

void crite(char** dest, char src, int index) {
    int i = 0;
    dest[index][0] = src;
    dest[index][1] = '\0';
    return;
}

void evaluate(char* args) {
    int i = 0;
    int j = 0;
    const char* numbers = "1234567890";
    const char* operators = "+-*/";
    int chunk = 0;
    char** chunks = calloc(24, sizeof(char*));
    char* current = calloc(24, sizeof(char));


    for (i = 0; strchr("\0\n", args[i]) == NULL; i++) {
        //printf("Args[i]:%c\n\n", args[i]);
        if (strchr(numbers, args[i]) != NULL) {
            //printf("Number added to current: %c\n\n", args[i]);
            current[j] = args[i];
            //printf("\nCurrent: %s\n", current);
            j++;
        } else if (strchr(operators, args[i]) != NULL) {
            write(chunks, current, chunk);
            chunk++;
            crite(chunks, args[i], chunk);
            chunk++;
            j = 0;
            free(current);
            current = calloc(24, sizeof(char));
            //printf("Terminated with operator and operator added.\n\n");
        } else {
            printf("ERROR: Encountered invalid token.\n\n");
            return;
        }

    }

    for (i = 0; chunks[i] != NULL; i++) 
        //printf("\n-Chunk: %s\n\n", chunks[chunk]);

    return;
}

int main(int argc, char** argv) {
    evaluate(argv[1]);
}

The command I used to compile it was gcc calculator.c -g -o calculator

Sample command: ./calculator 1*2

UPDATE: The issue with Valgrind was caused by the Windows subsystem I was using, so as long as you're running Valgrind on linux it should be fine. I tried it in a VM and it worked.

Also, thanks for helping me fix my Segmentation Fault even though that wasn't what the question was originally about:)

Answer 1

Running this code under valgrind resulting in the following:

[dbush@db-centos ~]$ valgrind /tmp/x1 1*2
==1431== Memcheck, a memory error detector
==1431== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==1431== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==1431== Command: /tmp/x1 1*2
==1431== 
==1431== Invalid write of size 1
==1431==    at 0x80484B3: write (x1.c:8)
==1431==    by 0x80485E8: evaluate (x1.c:39)
==1431==    by 0x804869D: main (x1.c:61)
==1431==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==1431== 
==1431== 
==1431== Process terminating with default action of signal 11 (SIGSEGV)
==1431==  Access not within mapped region at address 0x0
==1431==    at 0x80484B3: write (x1.c:8)
==1431==    by 0x80485E8: evaluate (x1.c:39)
==1431==    by 0x804869D: main (x1.c:61)
==1431==  If you believe this happened as a result of a stack
==1431==  overflow in your program's main thread (unlikely but
==1431==  possible), you can try to increase the size of the
==1431==  main thread stack using the --main-stacksize= flag.
==1431==  The main thread stack size used in this run was 10485760.
==1431== 
==1431== HEAP SUMMARY:
==1431==     in use at exit: 120 bytes in 2 blocks
==1431==   total heap usage: 2 allocs, 0 frees, 120 bytes allocated
==1431== 
==1431== LEAK SUMMARY:
==1431==    definitely lost: 0 bytes in 0 blocks
==1431==    indirectly lost: 0 bytes in 0 blocks
==1431==      possibly lost: 0 bytes in 0 blocks
==1431==    still reachable: 120 bytes in 2 blocks
==1431==         suppressed: 0 bytes in 0 blocks
==1431== Rerun with --leak-check=full to see details of leaked memory
==1431== 
==1431== For counts of detected and suppressed errors, rerun with: -v
==1431== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 13 from 8)

So at this line in write:

dest[index][i] = src[i];

You're dereferencing a NULL pointer and attempting to write there. The NULL pointer in question is dest[index], which is NULL since you used calloc to allocate the memory. Here's what you did do:

char** chunks = calloc(24, sizeof(char*));
char* current = calloc(24, sizeof(char));

You creating chunks as an array of pointers, but you didn't assign anything to those pointers. You need to loop through each array element and allocate space for each one:

char** chunks = calloc(24, sizeof(char*));
for (i=0; i<24; i++) {
    chunks[i] = calloc(24, sizeof(char));
}

Alternately, you can allocate this memory in write and crite before copying:

void write(char** dest, char* src, int index) {
    int i = 0;
    dest[index] = calloc(24, sizeof(char));
    for (i = 0; src[i] != '\0'; i++) {
        dest[index][i] = src[i];
    }
    dest[index][i] = '\0';
    return;
}

void crite(char** dest, char src, int index) {
    int i = 0;
    dest[index] = calloc(2, sizeof(char));
    dest[index][0] = src;
    dest[index][1] = '\0';
    return;
}

Answer 2

This is a stack trace from deep within the Linux loader. Valgrind creates a sandbox execution environment and loads your program into that, where its various tools can insert their own instrumentation code into your instruction stream.

This is exotic stuff: very dependent a good valgrind build and care in building your program under test correctly. This tiny stack trace alone can't possibly explain what's going wrong. The loader could be dying while trying to load valgrind. Or perhaps its dying within the sandbox as its trying to load you program. The problem could be in the valgrind binary or the binary for your program, causing the Linux loader to fail. It's even possible (I don't know) that valgrind includes its own copy of the loader, and that copy built incorrectly and so is dying.

The bigger picture is that valgrind isn't a good tool do debug a simple seg fault in your (I expect) small program. Two things much more likely to bear fruit are to build and run the program correctly so that gdb produces a correct symbolic stack trace and to simply insert fprintfs.

This ought to produce a stack trace with gdb:

$ gcc calculator.c -g -o calculator
$ gdb ./calculator
(gdb) run

If you need command line args to trigger the bug, you can give them with set args, e.g.

(gdb) set args 1*2
(gdb) run

If you're not seeing a stack trace, your build environment is almost certainly broken: there's something wrong with your compiler or gdb.

The other technique, which isn't very elegant but nonetheless can be effective is to add fprintf(stderr, ...)s starting with the first line in main() and periodically after. The last output tells you how far the execution got. When you're a beginning programmer, it can be more efficient to avoid learning new tools until you're familiar with the language, compiler, and write-compile-debug-revise cycle.

Answer 3

When I run your program I get a complaint from gdb about line 8 (my cut and paste wont work)

It seems like there is somehting serioulsy wrong with your toolchain

Can you even write and run a hello world program?

#include <stdio.h>
int main()
{
    printf("hello world\n");
}