I am writing a very simple struct called Process, and the code seems implemented correctly at a quick glance, but upon testing my code it seems to keep crashing the program, either by sysMalloc assertion failure or a double free() error when one attempts to free it.
Some relevant code:
Declaration
typedef struct Process{
    int pid;
    int background;
    int group;
    int status;
    char* name = 0;
} Process;
Constructor
Process* Process_init(char* name, int pid, int group, int background){
    Process* output    = (Process*)calloc(1, sizeof(Process*));
    output->name       = name;
    output->pid        = pid;
    output->group      = group;
    output->background = background;
    output->status     = 0;
    return output;
}
Calling code
char* command = "python";
char* command1= "cat < testing";
Process* proc = Process_init("command", 1, 1, 1);
Process* proc2 = Process_init("command1", 1, 1, 1);
There is some weird behavior where it appears to work the first time around, but causes the sysMalloc error when called a second time (which is why I call it twice.)
I tried using Valgrind and it gave me the following:
invalid write of size 4
==3485==    at 0x8049A03: Process_init (process.c:6)
==3485==    by 0x80488C2: main (test.c:58)
==3485==  Address 0x419e730 is 12 bytes after a block of size 4 alloc'd
==3485==    at 0x402425F: calloc (vg_replace_malloc.c:467)
==3485==    by 0x80499F9: Process_init (process.c:5)
==3485==    by 0x80488C2: main (test.c:58)
==3485== 
==3485== Invalid write of size 4
==3485==    at 0x8049A14: Process_init (process.c:8)
==3485==    by 0x80488C2: main (test.c:58)
==3485==  Address 0x419e728 is 4 bytes after a block of size 4 alloc'd
==3485==    at 0x402425F: calloc (vg_replace_malloc.c:467)
==3485==    by 0x80499F9: Process_init (process.c:5)
==3485==    by 0x80488C2: main (test.c:58)
==3485== 
==3485== Invalid write of size 4
==3485==    at 0x8049A1D: Process_init (process.c:9)
==3485==    by 0x80488C2: main (test.c:58)
==3485==  Address 0x419e724 is 0 bytes after a block of size 4 alloc'd
==3485==    at 0x402425F: calloc (vg_replace_malloc.c:467)
==3485==    by 0x80499F9: Process_init (process.c:5)
==3485==    by 0x80488C2: main (test.c:58)
==3485== 
==3485== Invalid write of size 4
==3485==    at 0x8049A23: Process_init (process.c:10)
==3485==    by 0x80488C2: main (test.c:58)
==3485==  Address 0x419e72c is 8 bytes after a block of size 4 alloc'd
==3485==    at 0x402425F: calloc (vg_replace_malloc.c:467)
==3485==    by 0x80499F9: Process_init (process.c:5)
==3485==    by 0x80488C2: main (test.c:58)
==3485== 
==3485== Invalid write of size 4
==3485==    at 0x8049A03: Process_init (process.c:6)
==3485==    by 0x80488EA: main (test.c:59)
==3485==  Address 0x419e768 is 12 bytes after a block of size 4 alloc'd
==3485==    at 0x402425F: calloc (vg_replace_malloc.c:467)
==3485==    by 0x80499F9: Process_init (process.c:5)
==3485==    by 0x80488EA: main (test.c:59)
==3485== 
==3485== Invalid write of size 4
==3485==    at 0x8049A14: Process_init (process.c:8)
==3485==    by 0x80488EA: main (test.c:59)
==3485==  Address 0x419e760 is 4 bytes after a block of size 4 alloc'd
==3485==    at 0x402425F: calloc (vg_replace_malloc.c:467)
==3485==    by 0x80499F9: Process_init (process.c:5)
==3485==    by 0x80488EA: main (test.c:59)
==3485== 
==3485== Invalid write of size 4
==3485==    at 0x8049A1D: Process_init (process.c:9)
==3485==    by 0x80488EA: main (test.c:59)
==3485==  Address 0x419e75c is 0 bytes after a block of size 4 alloc'd
==3485==    at 0x402425F: calloc (vg_replace_malloc.c:467)
==3485==    by 0x80499F9: Process_init (process.c:5)
==3485==    by 0x80488EA: main (test.c:59)
==3485== 
==3485== Invalid write of size 4
==3485==    at 0x8049A23: Process_init (process.c:10)
==3485==    by 0x80488EA: main (test.c:59)
==3485==  Address 0x419e764 is 8 bytes after a block of size 4 alloc'd
==3485==    at 0x402425F: calloc (vg_replace_malloc.c:467)
==3485==    by 0x80499F9: Process_init (process.c:5)
==3485==    by 0x80488EA: main (test.c:59)
--Snip--
So, it looks like the problem is in the constructor, but I'm not exactly sure why that is since it looks like a really straightforward moving around of variables.
 
     
    