Perhaps a resource not released? What could cause this?

Question

I'm working on a project and I came to a point where the following stack trace popped up:

#0  0x0017c30c in _IO_flush_all_lockp () from /lib/libc.so.6
#1  0x0017d030 in _IO_cleanup () from /lib/libc.so.6
#2  0x0013e042 in exit () from /lib/libc.so.6
#3  0x00126bbe in __libc_start_main () from /lib/libc.so.6
#4  0x08049d11 in _start ()

(Code removed because that memory leak was solved. There are others, of course. I'll try harder to track them down before posting them here though. :) The initial problem may not be related to memory leaks. )

First of all, am I even looking in the right direction from the initial stack trace? I've never seen this one before when dealing with memory issues. Any ideas?

Edit: Someone said it was due to visual_mem_new0. That function simply allocates memory. It knows nothing about plugin->author.

Edit: Duh. The memcopy right before the strdup fills the memory in.

Edit: Ok, that gets rid of the one memory leak. I'm not convinced the initial stack trace is all about a memory leak -- it's still there for example. It's trying to release some resource I believe. Part of this program uses a lot of compiled assembly (JIT compiler), which uses mmap'd memory on top of a file descriptor for a buffer. I'm closing the file. Is there something I need to do with the memory map?

I'll keep trying to clear these memory leaks out of the way, though. I did something recently that's related to a particular plugin. The program only hangs on close when I run that plugin, which uses the memory map I spoke of. I'm not sure what it could be. I made some minor changes. Initially I suspected a shared pointer that I keep track of references for. It uses the same system used all throughout libvisual, and no memory leaks specific of that is showing up. At any rate, I hope someone has some clues about it. I can't think of anything else to add.

Edit: Ok, tracked it down with the help of revision history. What's wrong with the following code? Can I not copy output onto itself like that?

static inline int dump_stack(AvsCompilerContext *ctx)
{
    AvsCompilerArgument *pa;
    char output[2048];

    snprintf(output, 2047, "\ncompiler: stackdump: Stack dump\n");
    for (pa=(AvsCompilerArgument *)ctx->stack->base; pa < (AvsCompilerArgument *)ctx->stack->pointer; pa++) {
        snprintf(stderr, 2047, "%scompiler: stackdump: [%2d] = ", output, (pa - (AvsCompilerArgument *)ctx->stack->base));
        switch (pa->type) {
            case AvsCompilerArgumentInvalid:
                snprintf(output, 2047, "%sinvalid", output);
                break;

            case AvsCompilerArgumentConstant:
                snprintf(output, 2047, "%s%.2f", output, pa->value.constant);
                break;

            case AvsCompilerArgumentIdentifier:
                snprintf(output, 2047, "%s", pa->value.identifier);
                break;

            case AvsCompilerArgumentMarker: {
                char *markers[] = { "invalid", "function", "argument", NULL };
                snprintf(output, 2047, "%s--- %s marker ---", output, markers[pa->value.marker]);
                break;
            }

            case AvsCompilerArgumentPrivate:
                snprintf(output, 2047, "%sprivate", output);
                break;

        }
        snprintf(output, 2047, "\n");
    }

    avs_debug(print(output));
    return VISUAL_OK;
}

The macro avs_debug does nothing. I commented its content out.

Answer 1

visual_plugin_info_new calls visual_mem_new0 which is allocating memory, you need to free the slots before assigning them in visual_plugin_info_copy.

Answer 2

Since you're doing strdup(), you should free the values using free(). I am not sure if visual_mem_free() calls free(). If you try free() instead of visual_mem_free(), does the valgrind error go away?

Edit: Your snprintf() calls are wrong:

snprintf(output, 2047, "%sinvalid", output);

snprintf() is C99, and the standard says (7.19.6.5p2):

If copying takes place between objects that overlap, the behavior is undefined.

The exact statement is for sprintf() in C89 as well.

The easiest way to fix your problem would be something like:

char init[] = "\ncompiler: stackdump: Stack dump\n";
size_t init_len = sizeof init - 1;
snprintf(output, 2047, "\ncompiler: stackdump: Stack dump\n");

followed by:

snprintf(output+init_len, sizeof output - init_len, "%.2f", pa->value.constant);

(Do check for off-by-one errors above.)

Also, I am not sure why you're calling snprintf() with stderr as its first argument in one of the calls. Are you compiling your code with warnings enabled?

Answer 3

There are probably at least 2 problems in the last snippet of code you've posted (the editing of the question leaves things very confusing as to what problem you're trying to deal with right now):

1. You have a line that starts snprintf(stderr, 2047, etc...). This is almost certainly a copy-paste error, as it shouldn't compile. You probably meant to use fprintf().

2. You cannot use the destination buffer also as a source in your snprintf() call. The standard says, "If copying takes place between objects that overlap, the behavior is undefined". If you think about it for a moment, you might realize that it couldn't work in the general case without first copying the buffer somewhere else. Try creating a wrapper around vsnprintf() (maybe named snprintfcat()) that concatenates the formatted string to the destination buffer. It's not too hard to do, though it requires using varargs which can be a bit tricky - but only a bit.

The following is a completely untested shot at an snprintfcat() function - it compiles, but beyond that use at your own risk:

int snprintfcat( char* dest, size_t siz, char const* fmt, ...)
{
    size_t len = strnlen( dest, siz);
    size_t remainder = 0;
    int result;

    va_list ap;

    if (len < siz) {
        remainder = siz - len;
    }

    va_start( ap, fmt);
    result = vsnprintf( dest+siz-remainder, remainder, fmt, ap);
    va_end( ap);

    return result + siz - remainder;
}