Error on variable declaration in C

Question

I'm having some trouble with a variable declaration in C which I hope you can help me with.

This code:

int makeDir(const char* path, mode_t mode) {
    printf("Checkpoint 1\n");
    String parentPath;
    printf("Checkpoint 2\n");
    pDirTreeNode parent;
    printf("Checkpoint 3\n");
    int idx, grp;
    pinode inod;
    pdir algo=NULL;
    printf("Checkpoint 4\n");
    pdir direntry=NULL;
    printf("Checkpoint 5\n");
    t_bitarray *bitarr;

    parent = malloc(sizeof(struct dirTreeNode));
    parentPath = malloc(DIR_NAME_SIZE);
    direntry=malloc(sizeof(struct s_direct));

    [COMMENTED code]
}

And these are the data type declarations:

typedef struct s_inode      *pinode;    
typedef struct s_direct     *pdir;      
typedef char                *String;    
typedef struct dirTreeNode  *pDirTreeNode; 

with s_inode and s_direct being declared in linux/ext2_fs.h header

I've executed it and when the program reaches the function it prompts:

Stopped due to shared library event /build/buildd/gdb-7.3/gdb/dwarf2loc.c:185: internal-error: dwarf_expr_frame_base: Assertion `framefunc != NULL' failed. A problem internal to GDB has been detected, further debugging may prove unreliable.

But it doesn't stops the debug session. Then, if I execute the rest of the code:

*** glibc detected *** /home/vlad/workspace_SisOp/RFSDev/Debug/RFSDev: realloc(): invalid next size: 0x0000000000a5cdf0 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7a6e6)[0x7fa21d6e26e6]
/lib/x86_64-linux-gnu/libc.so.6(+0x7d3e7)[0x7fa21d6e53e7]
/lib/x86_64-linux-gnu/libc.so.6(realloc+0xf9)[0x7fa21d6e6b39]
/home/vlad/workspace_SisOp/RFSDev/Debug/RFSDev[0x402cd3]
/home/vlad/workspace_SisOp/RFSDev/Debug/RFSDev[0x4017a4]
/home/vlad/workspace_SisOp/RFSDev/Debug/RFSDev[0x400af7]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7fa21d68930d]
/home/vlad/workspace_SisOp/RFSDev/Debug/RFSDev[0x4009e9]
======= Memory map: ========
00400000-00404000 r-xp 00000000 00:14 540784                             /home/vlad/workspace_SisOp/RFSDev/Debug/RFSDev
00603000-00604000 r--p 00003000 00:14 540784                             /home/vlad/workspace_SisOp/RFSDev/Debug/RFSDev
00604000-00605000 rw-p 00004000 00:14 540784                             /home/vlad/workspace_SisOp/RFSDev/Debug/RFSDev
00a5c000-00a7d000 rw-p 00000000 00:00 0                                  [heap]
7fa214000000-7fa214021000 rw-p 00000000 00:00 0 
7fa214021000-7fa218000000 ---p 00000000 00:00 0 
7fa21b706000-7fa21b71b000 r-xp 00000000 08:16 526333                     /lib/x86_64-linux-gnu/libgcc_s.so.1
7fa21b71b000-7fa21b91a000 ---p 00015000 08:16 526333                     /lib/x86_64-linux-gnu/libgcc_s.so.1
7fa21b91a000-7fa21b91b000 r--p 00014000 08:16 526333                     /lib/x86_64-linux-gnu/libgcc_s.so.1
7fa21b91b000-7fa21b91c000 rw-p 00015000 08:16 526333                     /lib/x86_64-linux-gnu/libgcc_s.so.1
7fa21b91c000-7fa21d668000 rw-p 00000000 00:14 273074                     /home/vlad/Sistemas Operativos/ext2.disk
7fa21d668000-7fa21d7ff000 r-xp 00000000 08:16 526221                     /lib/x86_64-linux-gnu/libc-2.13.so
7fa21d7ff000-7fa21d9fe000 ---p 00197000 08:16 526221                     /lib/x86_64-linux-gnu/libc-2.13.so
7fa21d9fe000-7fa21da02000 r--p 00196000 08:16 526221                     /lib/x86_64-linux-gnu/libc-2.13.so
7fa21da02000-7fa21da03000 rw-p 0019a000 08:16 526221                     /lib/x86_64-linux-gnu/libc-2.13.so
7fa21da03000-7fa21da09000 rw-p 00000000 00:00 0 
7fa21da09000-7fa21da2a000 r-xp 00000000 08:16 523159                     /lib/x86_64-linux-gnu/ld-2.13.so
7fa21dc10000-7fa21dc13000 rw-p 00000000 00:00 0 
7fa21dc26000-7fa21dc29000 rw-p 00000000 00:00 0 
7fa21dc29000-7fa21dc2a000 r--p 00020000 08:16 523159                     /lib/x86_64-linux-gnu/ld-2.13.so
7fa21dc2a000-7fa21dc2c000 rw-p 00021000 08:16 523159                     /lib/x86_64-linux-gnu/ld-2.13.so
7fff21b19000-7fff21b3a000 rw-p 00000000 00:00 0                          [stack]
7fff21ba2000-7fff21ba3000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Checkpoint 1
Checkpoint 2
Checkpoint 3
Checkpoint 4
Checkpoint 5

In a debug session, the code is actually exploding just after perror("1"), so it seems is not just a perror's problem...

Thanks in advance!

Edit: I've changed the dump messages and the function's code to avoid perrors. Also, this is the full main code:

pext2fs fsys; // Variable global

int main(int argv, char *argc[]) {
    fsys = malloc(sizeof(struct ext2system));

    getsysdata();

    /*                                              *
     *                                              *
     *                                              *
     * File System Client here                      *
     *                                              *
     *                                              *
     *                                              */

    /* ------------------>Código para probar funciones<------------------ */

    pDirTreeNode node;
    StringArray test;
    void **file=malloc(0);
    int ctrl, mode=0x1000;
    pdir *dirents;

    makeDir("\\Dir2\\DirCreadoInternamente", mode);
    node = getDirTreeNode("\\Dir2\\DirCreadoInternamente");
    //  dirents = list_dir(fsys->root);
    //  node = getDirTreeNode("\\Dir3\\UnDir");
    //  ctrl = getFile(&file, "\\Dir1\\LPD");
    //  printFile(file);

    /* ------------------>Fin del código de testing<------------------ */

    unmap(fsys->diskmap);

    return 0;
}

Answer 1

The perror() function prints an error message that depends on the current value of errno. It makes sense to call it only after calling a function that sets errno.

For example:

String parentPath;
perror("2");

You haven't done anything that would set errno to a meaningful value, so you're getting garbage. (errno was probably set to EINVAL as a side effect of the previous call to perror()).

The value of errno tells you which error occurred. Before checking it (either by examining errno or calling perror()), you should first determine whether an error occurred. Most functions that set errno also return a value that indicates success or failure. For example, malloc() returns a null pointer when it fails.

Answer 2

Various library functions may set errno to arbitrary values, but unless they return an error value, no error has actually occurred, and you should not trust errno otherwise.