c: variable length arrays

Another feature of c99 is variable length arrays.
Before c99 array size had to be declared during compile time. Now array is an array of automatic storage duration whose length is determined at run time.

int size = strlen(*argv);
char array[size];

The variable-sized arrays can be used only in stack scope. The memory for this type of arrays is gotten from the stack, so in file(global) scope you still unable to define variable-sized arrays.

This is not the same as alloca.
Variable size arrays' space is freed at the end of the scope of the name of the array while the space allocated with alloca remains until the end of the function.
Use alloca within a loop it's possible to allocate an additional block on each iteration. This is impossible with variable-sized arrays.

c++ doesn't have this feater but g++ supports it as an extension.

c++: virtual inheritance

Virtual inheritance is an important thing when we are talking about multiply inheritance.
Basically you can find term 'virtual base class' which means that the base class that is met in inheritance tree is shared between derived classes.
Let's look on the inheritance tree w/o virtual base class

class A
{
};
class B : public A
{
};
class D : public A
{
};
class E : public B, public D
{
};

Class E will have 2 copies of A(derived from B and D). To be more concrete let's look at the output of -fdump-class-hierarchy g++ option

Class A
   size=1 align=1
   base size=0 base align=1
A (0xb7f32680) 0 empty

Class B
   size=1 align=1
   base size=1 base align=1
B (0xb7f326c0) 0 empty
  A (0xb7f32700) 0 empty

Class D
   size=1 align=1
   base size=1 base align=1
D (0xb7f32740) 0 empty
  A (0xb7f32780) 0 empty

Class E
   size=2 align=1
   base size=2 base align=1
E (0xb7f327c0) 0 empty
  B (0xb7f32800) 0 empty
    A (0xb7f32840) 0 empty
  D (0xb7f32880) 1 empty
    A (0xb7f328c0) 1 empty

Indeed, the most obvious is the overhead: E contains 2 instances of A(by addresses 0xb7f32840 and 0xb7f328c0).
The other thing you are unable to call methods of A from E directly. There is no distinct path from E to A. The following code wouldn't be compiled. The compiler will raise an error that reference to methodA is ambiguous.

class A
{
    public:
        virtual void methodA(){}
};
class B : public A
{
};
class D : public A
{
};
class E : public B, public D
{
    virtual void methodE(){ methodA(); }
};

In this case you should explicitly call methodA either from B or D

virtual void methodE(){ B::methodA(); D::methodA(); }

Also you can face a problem with A as a base of E

A *a = new E;//‘A’ is an ambiguous base of ‘E’

You say you can do smth like this

A *a; 
    E *e = new E;
    void *v = (void *)e;
    a = (A *)v;

No chance to expect defined behavior with this piece of c-ish code.

Now let's look how things change w/ virtual base class.

class A
{
};
class B : virtual public A
{
};
class D : virtual public A
{
};
class E : public B, public D
{
};

Class A was defined as a virtual base class in the code above. Let's look what g++ says

Class A
   size=1 align=1
   base size=0 base align=1
A (0xb7f7a680) 0 empty

Class B
   size=4 align=4
   base size=4 base align=4
B (0xb7f7a6c0) 0 nearly-empty
    vptridx=0u vptr=((& B::_ZTV1B) + 12u)
  A (0xb7f7a700) 0 empty virtual
      vbaseoffset=-0x00000000c

Class D
   size=4 align=4
   base size=4 base align=4
D (0xb7f7a7c0) 0 nearly-empty
    vptridx=0u vptr=((& D::_ZTV1D) + 12u)
  A (0xb7f7a800) 0 empty virtual
      vbaseoffset=-0x00000000c

Class E
   size=8 align=4
   base size=8 base align=4
E (0xb7f7a880) 0
    vptridx=0u vptr=((& E::_ZTV1E) + 12u)
  B (0xb7f7a8c0) 0 nearly-empty
      primary-for E (0xb7f7a880)
      subvttidx=4u
    A (0xb7f7a900) 0 empty virtual
        vbaseoffset=-0x00000000c
  D (0xb7f7a940) 4 nearly-empty
      subvttidx=8u vptridx=12u vptr=((& E::_ZTV1E) + 24u)
    A (0xb7f7a900) alternative-path

Class E has one instance of A(by address 0xb7f7a900). We got rid of overhead. In the output you can see that there is only one path from A to E. There is no problem with compiling the following code

class E : public B, public D
{
    virtual void methodE(){ methodA(); }
};

And A can be used as a base class for E

A *a = new E;

With virtual inheritance we achieve better object model but we can loose some performance in order to run-time resolving paths to base from derived and from base to derived classes through v-table. With small classes we can even get overhead if v-table is pretty big.

The other thing you should be aware that c-style casting between derived and base classes(both ways) may break your program. Use dynamic_cast instead. That is because with the v-table classes not more of POD(Plain Old Data) types. c-style casts won't work correctly with non-POD types.

c++: specialization of template function

There some differences between template classes and template functions.
In c++ it isn't possible to overload classes but it's possible to overload functions.

Since you are able to overload function you should consider what actually you are doing.
Lets glance at the code below

template<typename T>
void func(T t) 
{
}

template<>
void func<int *>(int *t)
{
}

template<typename T>
void func(T *t)
{
}

Here is template function, specialization of template function and overloaded template function(it's still primary template).
What function will be called in case of

int *i = new int(10);
func(i);

Let's see. We have 2 primary template and 1 template specialization. The standard(13.3.2 Function Template Overloading) says that non-template functions have the highest priority(we don't have any here). Then if there no non-template functions(or none of them suitable) primary-template functions are being examined. There is no defined behavior which would be chosen among the available, probably compiler will ask developer to explicitly specify the template function(we have 2 primary template functions). If there are some specialization of template function compiler can make a decision w/o developer which is the most suitable in case when there is no primary template function that fits better.
In the code above primary template function will be called

template<> void func<int *>(int *t)

Is it possible to call specialized template function for the code below?

int *i = new int(10); func(i);

The answer is yes and the thing that should be done is specialization of overloaded template function

template<>
void
func<int>(int *t)
{
}

This is the specialization of the

template<typename T>
void func(T *t)
{
}

The specialization should appear _after_ the primary template in the code, so the complete piece of code is

template<typename T>
void func(T t) 
{
}

template<>
void func<int *>(int *t)
{
}

template<typename T>
void func(T *t)
{
}

template<>
void func<int>(int *t)
{
}

With this code

template<> void func<int>(int *t)

will be called for

int *i = new int(10);func(i);

The key is that the specialization is not overloading, to be more clear specialization _do_not_ overload functions. Specialization of template function is being examined only after the primary template has been chosen.
The better way I see here is to create non-template function

void func(int *t)
{
}

This one will be chosen first if there is no ambiguity in the prototypes.

c: designated initializers for structures

c99 came with a feature of designated initializers.
A designated initializer, or designator, points out a particular element to be initialized. A designator list is a comma-separated list of one or more designators.

struct
{
    int a; 
    int b; 
    int c; 
} s = {.a = 1, .c = 2};

Unfortunately c++ doesn't have this very handy feature.

c/c++: call stack

A lot of languages such as python, java, ruby etc. produce call trace on exception.

In c/c++ you don't have such opportunity.
Only playing with a debugger it's possible to view the call trace.

In glibc(since 2.1) you can find backtrace function defined in execinfo.h
This function returns a backtrace for the calling program(addresses of the functions).
Using backtrace function with backtrace_symbols you can get symbol names.
backtrace_symbols returns the symbolic representation of each address consists of the function
name (if this can be determined), a hexadecimal offset into the function, and the actual return address (in hexadecimal) according to the man pages. It should look like:

message: ./a.out(_Z1cv+0x19) [0x80488ad]
message: ./a.out(_Z1bv+0xb) [0x804896f]
message: ./a.out(_Z1av+0xb) [0x804897c]
message: ./a.out(main+0x16) [0x8048994]
message: /lib/libc.so.6(__libc_start_main+0xfb) [0xb7e2764b]

In c++, due to function overloading, namespaces, etc., names of the functions are being mangled. It's hard to read this traceback. I really didn't want to parse each string to extract function names but tried to use dladdr, glibc extension for dlfcn. dladdr returns function name and the pathname of shared object that contains this function. Unfortunately dladdr still returns mangled name of the function.
Unexpectedly I have found __cxa_demangle hidden in the caves of g++. This function demangles function name. This is what I was looking for.
The short example of traceback generation:

#include <stdio.h>
#include <signal.h>
#include <execinfo.h>
#include <cxxabi.h>
#include <dlfcn.h>
#include <stdlib.h>

void c()
{
    using namespace abi;

    enum
    {  
        MAX_DEPTH = 10 
    }; 

    void *trace[MAX_DEPTH];

    Dl_info dlinfo;

    int status;
    const char *symname;
    char *demangled;

    int trace_size = backtrace(trace, MAX_DEPTH);

    printf("Call stack: \n");

    for (int i=0; i<trace_size; ++i)
    {  
        if(!dladdr(trace[i], &dlinfo))
            continue;

        symname = dlinfo.dli_sname;

        demangled = __cxa_demangle(symname, NULL, 0, &status);
        if(status == 0 && demangled)
            symname = demangled;

        printf("object: %s, function: %s\n", dlinfo.dli_fname, symname);

        if (demangled)
            free(demangled);
    }  
}

void b()
{
    c();
}

void a()
{
    b();
}

int main(int argc, char **argv)
{
    a();

    return 0;
}

The executable should be compiled with -rdynamic g++ flag to instruct the linker to add all symbols, not only used ones, to the dynamic symbol table.

g++ test.cc -ldl -rdynamic -o test

The output:

Call stack: 
object: ./test, function: c()
object: ./test, function: b()
object: ./test, function: a()
object: ./test, function: main
object: /lib/libc.so.6, function: __libc_start_main

If gcc optimization have been used you may not see the whole traceback in some cases. With -O2/-O3

Call stack: 
object: ./test, function: c()
object: ./test, function: main
object: /lib/libc.so.6, function: __libc_start_main

perl: $#

I was confused by some perl tutorials/books that claim you can use $# to get the size of an array.

Actually $# returns the last index of the array. The things can be messed with $[, special perl variable that stands for the index of the first element in an array.
But if environment haven't been modified $# will return 'size of the array' - 1.

To get amount of elements the array should be used in scalar context or using scalar function.

Please, don't use $# to get the amount of the elements in the array. You may confuse your followers and yourself.

c: initializing arrays

There various ways to initialize array in c99.

One dimensional array you can initialize just enumerating the values sequentially. Values not initialized explicitly will be initialized with zeros.

int array[3] = {1, 2, 3};

Also you can specify values with designated initializers.

int array[3] = {1, [2] = 3};

In the example above array[0] is 1, array[1] is 0(implicitly initialized) and array[2] is 3.
Multidimensional arrays can be initialized with enumerating the values sequentially.

int array[2][2] = {1, 2, 3, 4};

The values 1, 2, 3, 4 will be assigned to array[0], array[1], array[2], array[3] correspondingly. Grouping the values of the elements of nesting level of elements is more expressive.

int array[2][2] = {{1, 2}, {3, 4}};

As one dimensional arrays multidimensional can be initialized by designated initializers assigning value to each element

int array[2][2] = {[0][0] = 1, [0][1] = 2, [1] = {3, 4}};

or grouping by level

int array[2][2] = {[0] = {1, 2}, [1] = {3, 4}};

linux: change the process' name

From time to time developers want to modify the command line of program that is shown in ps or top utilities.
There is no API in linux to modify the command line.
This article is linux specific but I hope that following these steps you can do it in almost every OS(BTW, FreeBSD has setproctitle routine that should do the job).

Both ps and top tools comes from procps package in all linux distribution I worked with. So they have the same base and let's stop on ps because it's a bit easier to investigate it.
To figure out how ps gets information about the processes let's simply trace it

$strace ps aux 2>&1 1>/dev/null|grep $$
stat64("/proc/4391", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
open("/proc/4391/stat", O_RDONLY)       = 6
read(6, "4391 (bash) S 4388 4391 4349 348"..., 1023) = 222
open("/proc/4391/status", O_RDONLY)     = 6
open("/proc/4391/cmdline", O_RDONLY)    = 6
readlink("/proc/4391/fd/2", "/dev/pts/1", 127) = 10
read(6, "4760 (strace) S 4391 4760 4349 3"..., 1023) = 208
read(6, "4761 (grep) S 4391 4760 4349 348"..., 1023) = 196
read(6, "grep\0004391\0", 2047)         = 10

As expected it reads information from procfs.

$cat /proc/$$/cmdline
bash

Now prepare yourself, I'm going to dig into the kernel sourses.

Looking into fs/proc/base.c I found desired function proc_pid_cmdline that is used to show the command line in /proc/<pid>/cmdline
The part of it that we are interested:

static int proc_pid_cmdline(struct task_struct *task, char * buffer) {
...
    struct mm_struct *mm = get_task_mm(task);

...

    len = mm->arg_end - mm->arg_start;
 
    if (len > PAGE_SIZE)
        len = PAGE_SIZE;

    res = access_process_vm(task, mm->arg_start, buffer, len, 0);

    // If the nul at the end of args has been overwritten, then
    // assume application is using setproctitle(3).
    if (res > 0 && buffer[res-1] != '\0' && len < PAGE_SIZE) {
        len = strnlen(buffer, res);
        if (len < res) {
            res = len;
        } else {
            len = mm->env_end - mm->env_start;
            if (len > PAGE_SIZE - res)
                len = PAGE_SIZE - res;
            res += access_process_vm(task, mm->env_start, buffer+res, len, 0);
            res = strnlen(buffer, res);
        }    
    }    
...

That's funny but in comments mentioned setproctitle(3). After I saw these lines I tried to find setproctitle for linux but failed. It's interesting why is mentioned here as it available in FreeBSD but not in linux.
Anyway let's move forward.
The most interesting parts here are

len = mm->arg_end - mm->arg_start;
 
    if (len > PAGE_SIZE)
        len = PAGE_SIZE;

    res = access_process_vm(task, mm->arg_start, buffer, len, 0);

access_process_vm, defined in mm/memory.c, accesses another process' address space. The prototype:

int access_process_vm(struct task_struct *tsk, unsigned long addr, void *buf, int len, int write)

Fifth argument write is a flag, if it is 0 then access_process_vm reads len bytes of the process' memory to buf starting from address addr.
Going back to proc_pid_cmdline we can see that start address of the string with the command line is mm->arg_start and its length is mm->arg_end - mm->arg_start but not bigger than PAGE_SIZE. PAGE_SIZE is set to 4096 bytes as defined in include/asm-i386/page.h

#define PAGE_SHIFT 12
#define PAGE_SIZE (1UL << PAGE_SHIFT)

Well, now we know that we have 4KB where we can write.

Who fills the memmory between mm->arg_start and mm->arg_end and what is stored there?
I hope everybody uses ELF binary format now. So let's go to fs/binfmt_elf.c
The name of the function that creates process environment is create_elf_tables.
The part of it we are actually interested in:

static int
create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
        unsigned long load_addr, unsigned long interp_load_addr) {
...
    /* Populate argv and envp */
    p = current->mm->arg_end = current->mm->arg_start;
    while (argc-- > 0) {
        size_t len;
        if (__put_user((elf_addr_t)p, argv++))
            return -EFAULT;
        len = strnlen_user((void __user *)p, MAX_ARG_STRLEN);
        if (!len || len > MAX_ARG_STRLEN)
            return -EINVAL;
        p += len;
    }
    if (__put_user(0, argv))
        return -EFAULT;
    current->mm->arg_end = current->mm->env_start = p;
    while (envc-- > 0) {
        size_t len;
        if (__put_user((elf_addr_t)p, envp++))
            return -EFAULT;
        len = strnlen_user((void __user *)p, MAX_ARG_STRLEN);
        if (!len || len > MAX_ARG_STRLEN)
            return -EINVAL;
        p += len;
    }
    if (__put_user(0, envp))
        return -EFAULT;
    current->mm->env_end = p;
...

According to create_elf_tables argv points to current->mm->arg_start and current->mm->arg_end points to the end of the environment(envp).

To modify cmdline of the process you have to overwrite memory between current->mm->arg_start and current->mm->arg_end and to keep program's integrity move its environment.

Looking into the sources of getenv/setenv we can see that they access **environ variable(environ(7)). environ is declared in the <unistd.h> but it's preffered to declare it in the user program as

extern char **environ;

The following code rewrites cmdline of the process and moves environment to it's new 'home'.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <limits.h>
#include <sys/user.h>

extern char **environ;

int main(int argc, char **argv)
{   
    unsigned int pid = getpid();
    char proc_pid_cmdline_path[PATH_MAX];
    char cmdline[PAGE_SIZE];
    
    sprintf(proc_pid_cmdline_path, "/proc/%d/cmdline", pid);
    
    FILE *proc_pid_cmdline =  fopen(proc_pid_cmdline_path, "r");
    fgets(cmdline, PAGE_SIZE, proc_pid_cmdline);
    fclose(proc_pid_cmdline);
    
    printf("%s : %s\nenvironment variable HOME = %s\n", proc_pid_cmdline_path, cmdline, getenv("HOME"));
    
    int env_len = -1;
    if (environ) 
        while (environ[++env_len])
            ;
    
    unsigned int size;
    if (env_len > 0)
        size = environ[env_len-1] + strlen(environ[env_len-1]) - argv[0];
    else
        size = argv[argc-1] + strlen(argv[argc-1]) - argv[0];
    
    if (environ)
    {
        
        char **new_environ = malloc(env_len*sizeof(char *));
        
        unsigned int i = -1;
        while (environ[++i])
            new_environ[i] = strdup(environ[i]);
        
        environ = new_environ;
    }   
        
    
    char *args = argv[0];
    memset(args, '\0', size);
    snprintf(args, size - 1, "This is a new title and it should be definetely longer than initial one. Actually we can write %d bytes long string to the title. Well, it works!", size);
    
    proc_pid_cmdline =  fopen(proc_pid_cmdline_path, "r");
    fgets(cmdline, PAGE_SIZE, proc_pid_cmdline);
    fclose(proc_pid_cmdline);
    
    printf("%s : %s\nenvironment variable HOME = %s\n", proc_pid_cmdline_path, cmdline, getenv("HOME"));
    
    return 0; 
}

The output should be

$./chcmdline 
/proc/5865/cmdline : ./chcmdline
environment variable HOME = /home/niam
/proc/5865/cmdline : This is a new title and it should be definetely longer than initial one. Actually we can write 1843 bytes long string to the title. Well, it works!
environment variable HOME = /home/niam

There is an option to expand memory region that we can overwrite. Just assign environment variable for the process:

$ENV_VAR=$(perl -e 'print "0" x 4096;') ./chcmdline 
/proc/5863/cmdline : ./chcmdline
environment variable HOME = /home/niam
/proc/5863/cmdline : This is a new title and it should be definetely longer than initial one. Actually we can write 5948 bytes long string to the title. Well, it works!
environment variable HOME = /home/niam

That small perl script prints "0" 4096 times to stdout, so as we can see the memory size of environment grew up to 5948 bytes.

This code might be portable to other OSes, I don't know. In general in POSIX system with gcc compiler you might be successfull with this code.

bash: file descriptors

In bash you may open file descriptor for reading or(and) writing.
To create file descriptor for reading, writing, reading and writing use these commands:

[fd]<[source] #read-only
[fd]>[source] #write-only
[fd]<>[source] #read-write

[fd] is a digit that describes file descriptor and [source] can be either another file descriptor(should be with leading &) or any other source for reading or writing.
If the source is other file descriptor the new one will be a duplicate.

#file descriptor 3 is opened for reading
#and already contains '123' which comes from the 'echo' command
3< <(echo 1 2 3)
#file descriptor 3 is opened for writing
#which output will be printed to stdout by 'cat' tool
3> >(cat)
#file descriptor 3 is opened for reading/writing
#from/to test.file file
3<>test.file

To move descriptor add '-' suffix to the [source] descriptor.

3<&2- #stderr is redirected to descriptor 3 and closed

By executing

ls -l /proc/$$/fd

you can see what file descriptors are opened for current process.
Using exec for creating/redirecting/duplicating file descriptors allows the changes to take effect in the current shell. Otherwise they are local to subroutine.

#file descriptor 3 is local for 'while' loop
#you can't use it outside
while read line <&3; do echo $line; done 3<test.file

#file descriptor 3 is visible within current process
exec 3<test.file
while read line <&3; do echo $line; done

Special cases of redirection to stdin of the program are 'Here Documents' and 'Here Strings'.

#the shell reads input from the current source until
#a line containing only [word] (with no trailing blanks) is seen
<<[word]
#the shell reads input from the current source until
#a line containing only [word] (with no trailing blanks) is seen
#but all leading tab characters are stripped from input lines and the line containing [word]
<<-[word]
#[word] is expanded and supplied to the command on its standard input
<<<[word]

The examples

$exec 3<<EOF
> text is here
> EOF
$cat <&3
text is here

$exec 3<<<string
$cat <&3
string

gdb: modify values of the variables

While you debugging your application you likely want to change behavior a bit.
With gdb you can change values of the variables with set command:

(gdb) whatis a
type = int

By variable name

(gdb) p a
$1 = 5
(gdb) set var a = 10
(gdb) p a
$2 = 10

By variable address

(gdb) p a
$2 = 10
(gdb) p &a
$3 = (int *) 0xbff5ada0
(gdb) set {int}0xbff5ada0 = 15
(gdb) p a
$4 = 15

gdb: examining the core dumps

When your program receives SIGSEGV(Segmentation fault) kernel automatically terminates it(if the application doesn't handle SIGSEGV).
After a couple of long nights of debugging, tracing and drinking coffee you finally find the line in the sources where your application causes system to send this crafty signal.

The most general problem is that you usually unable to run application withing debugger. The fault may be caused by special circumstances. It's really painful to sit in front of the debugger and trying to reproduce the fault. More complexity add multi-threading/processing, network interaction.

Core dumps would be a good solution here.
The linux kernel is able to write a core dump if the application crashes. This core dump records the state of the process at the time of the crash.

Later you can use gdb to analyze the core dump.

Core dumps are disabled by default in linux.
To enable you should run

ulimit -c unlimited

By default kernel writes core dump in the current working directory of the application. You may customize the pattern of file path for core dumps by writing it to /proc/sys/kernel/core_pattern.
According to current documentation pattern consists of following templates

%%  A single % character 
%p  PID of dumped process 
%u  real UID of dumped process 
%g  real GID of dumped process 
%s  number of signal causing dump 
%t  time of dump (secs since 0:00h, 1 Jan 1970) 
%h  hostname (same as the 'nodename' returned by uname(2)) 
%e  executable filename

So with

echo /tmp/%e-%p.core > /proc/sys/kernel/core_pattern

linux should put core dumps into /tmp with -.core filename.
Let's try all this.
Say we have this code

void
crash()
{
    char a[0];
    free(a);
}
int
main(int argc, char **argv)
{
    crash();
    return 0;
}

As you can see application should cause segmentation violation on free call. Let's compile it

gdb test.c -g -o test

and execute

./test 
Segmentation fault (core dumped)

System tells us that core was dumped. Let's see what we have

ll /tmp/*core
-rw------- 1 niam niam  151552 2008-10-15 15:19 /tmp/test-25301.core

Got it. Now I'm going to run gdb

gdb --core /tmp/test-25301.core ./test

gdb clearly tells that application was terminated with SIGSEGV

Core was generated by `./test'.
Program terminated with signal 11, Segmentation fault.
#0  0xb7e4ff97 in free () from /lib/libc.so.6

Now we can use power of gdb to catch the problem code

(gdb) bt
#0  0xb7e4ff97 in free () from /lib/libc.so.6
#1  0x08048392 in crash () at 1.c:9#2  0x080483aa in main () at 1.c:15
(gdb) up
#1  0x08048392 in crash () at 1.c:99  free(a);
(gdb) p a
$1 = 0xbfc5daf8 "\b�ſ�\203\004\b�D�� �ſx�ſ��߷�����\203\004\bx�ſ��߷\001"
(gdb) whatis a
type = char [0]
(gdb) info frame
Stack level 1, frame at 0xbfc5db00:
 eip = 0x8048392 in crash (1.c:9);
 saved eip 0x80483aa called by frame at 0xbfc5db10, caller of frame at 0xbfc5daf0
 source language c.
 Arglist at 0xbfc5daf8, args:
 Locals at 0xbfc5daf8, Previous frame's sp is 0xbfc5db00
 Saved registers:
  ebp at 0xbfc5daf8, eip at 0xbfc5dafc

We can see here that free attempted to free memory of the stack. It shows 'whatis a' and we see that address of a is in the stack(esp holds 0xbfc5db00 and a is stored at 0xbfc5daf8 - just in the beginning of the stack).
gdb gave all needed information for further investigation. The only thing left is to understand who tought you to free array on the stack o_O.

c/c++: array subscripting operator [ ]

Everybody knows that operator [] allows to specify the element of the array.
Using the knowledge about the arrays, which says that the elements of the array are stored sequentially in the memory we can recall that the elements of the array can be accessed using pointer arithmetic.

int a[] = {1,2,3};
std::cout << "First:" << *a << std::endl;
std::cout << "Second:" << *(a + 1) << std::endl;
std::cout << "Third:" << *(a + 2) << std::endl

So, the expression a[index] is equivalent to the expression *(a + index). According to arithmetic rules

*(a + index) == *(index + a)

What does that mean? That means that using the definition of operator [], which says the expression a[b] is equivalent to the expression *((a) + (b)), we can write

int a[] = {1,2,3};
std::cout << "First:" << 0[a] << std::endl;
std::cout << "Second:" << 1[a] << std::endl;
std::cout << "Third:" << 2[a] << std::endl

This is similar to the first listing and to the traditional style

int a[] = {1,2,3};
std::cout << "First:" << a[0] << std::endl;
std::cout << "Second:" << a[1] << std::endl;
std::cout << "Third:" << a[2] << std::endl

c++: implicit typenames in templates

Template object is an incomplete type, for an obvious reason in some cases it's hard for compiler to decide what typename should be. Let's look at the this example

template<typename T>
class A
{
    public:
        struct B
        {
            T member;
        };
};

template<typename T>
class C
{
    public:
        A<T>::B member;
};

Your(and mine also ;]) compiler will probably tell you " type A<T> is not derived from type C<T>". A<T> is undefined, so A<T>::B is undefined also.
To make this work you have to tell compiler explicitly that A<T>::B is a typename.

template<typename T>
class A
{
    public:
        struct B
        {
            T member;
        };
};

template<typename T>
class C
{
    public:
        typename A<T>::B member;
};