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;
}

The definition `typedef char *String;` is a bad idea. A *string*, in C, is a sequence of characters; a pointer is not a string, but can be used to manipulate strings. Just use `char*` directly. — Keith Thompson, Jun 24 '12 at 03:33
I was using a malloc on that string, but I moved it down to test whether it was the malloc or the declaration which was failing. — Vladimir, Jun 24 '12 at 03:47
Many people, including myself, disagree with Keith's opinion. — Jim Balter, Jun 24 '12 at 07:05
@JimBalter, I don't see what in Keith' comment is an opinion. — Jens Gustedt, Jun 24 '12 at 08:10
@JensGustedt All normative assertions are opinions. Perhaps you overlooked the words "bad idea". — Jim Balter, Jun 24 '12 at 08:14
@JimBalter: Because the code used `String`, I was unable to understand it without finding and reading the definition of `String` (which, in real life, might be buried in some obscure header). If it had used `char*`, I would have understood the declaration immediately. Furthermore, using the name `String` reinforces the misconception that strings are pointers. — Keith Thompson, Jun 24 '12 at 15:29
@JimBalter: Headers and typedefs can be misused. Typedefs for pointer types are usually a bad idea; see, for example, http://stackoverflow.com/q/750178/827263. (Thanks for the welcome, but I've been using C for about 30 years.) — Keith Thompson, Jun 24 '12 at 20:58
The welcome is a direct response to your complaint. Also, you've moved the goalposts from "String is a bad idea" (which, again, I disagree with) to the ability to read code snippets, which is frankly a silly complaint. And now you broaden your opinion to *all* typedefs for pointer types, which even more people disagree with. I've written in C for 35 years and have seen a lot of idiosyncratic preferences passed off as fact -- the longer term programmers seem more prone to them (I do it occasionally myself). End of discussion for me; have a nice day. — Jim Balter, Jun 24 '12 at 21:13
Just a bit more: I myself have used String typedefs but not ptype typedefs as the latter achieve nothing but change '*' to 'p' and move it around. But it's a matter of choice. And also, anything at all can be misused; that is not an HONEST complaint; it is not part of an HONEST exchange. Good day. — Jim Balter, Jun 24 '12 at 21:16

score 2 · Answer 1 · answered Jun 24 '12 at 03:32

2

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.

answered Jun 24 '12 at 03:32

Keith Thompson

254,901
44
429
631

Hi Keith, thanks for the answer. I wrote those perrors because the program **is** actually exploding when I reach that point on a debug session. In fact, the session ended without reaching the perror sentence, it's only running the program that I get that output. Any hint? (btw, I appreciate this answer that you gave me, it's useful even not solving the original prob (: ) – Vladimir Jun 24 '12 at 03:43
Sorry, I didn't knew what you just explained so I thought it was clear that it was something wrong just before perror("2") execution. Well, that's the problem then. (Really, sorry guys :/ ) – Vladimir Jun 24 '12 at 03:52
@Vladimir: The useless `perror` calls are obscuring tbe problem. The place where you say it's blowing up simply declares a `char*` object; there's no way that should cause such a problem. Show us code, preferably a self-contained program, without the `perror` calla, and tell us *exactly* where and how it fails (without using the word "explodes" unless it literally explodes). – Keith Thompson Jun 24 '12 at 15:36
I've edited the question, it's all there now. Ok, it doesn't explodes, it just suddenly stops the execution and prompts a dump :P – Vladimir Jun 24 '12 at 19:34

score 1 · Answer 2 · answered Jun 24 '12 at 03:31

1

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.

answered Jun 24 '12 at 03:31

Ignacio Vazquez-Abrams

776,304
153
1,341
1,358

Error on variable declaration in C

2 Answers2