Thread: Shell Programming - Process Table

I do walk the the list in the subsequent lines of code but since the debugger stops before doing it and I'm at the first function call I avoid posting it. Also walking through the debugger the process is quite simple:

there is a global variable job that points to the list, and in the operation temp points to it first. Addition to the list is done from the beginning, and at the time of the call there are two elements.

You can't walk the list in the successive lines of code. How do you find the element to delete without walking the list?

Actually toDel or temp at that point points to the first element. Hence nothing points to it other than temp.

I do walk the list, but only later so the problem is before. All what happens before is adding to a global list two nodes, and then try to delete the first (head) one, which results in the above.

This line job = temp->next, means that the global list should now point to its second element. Then I try to free the first, now point to only by temp.

Looks like you don't get what I try to say. The debugger doesn't go past the free(temp) call. So adding any line past it won't help.

I don't walk the list, I check right away the first element, and it happens to be the desired element to delete.

Originally Posted by simpatico_qa

Looks like you don't get what I try to say. The debugger doesn't go past the free(temp) call. So adding any line past it won't help.

I don't walk the list, I check right away the first element, and it happens to be the desired element to delete.

If that's what's actually happening, you wouldn't be getting errors. Since you're getting errors, that's not what's happening. If free(temp) is throwing an error, then temp must not point at memory that was malloc'ed (either it's a pointer to New Jersey, or you've passed in an array). So show your code.

This is getting interesting. Actually in the debugger I see that both jobs and temp point to the list nodes (structures) wanted.

I've attached a screenshot of the debugger with memory addresses.

I'll remark again, on Mac OS X this is not an issue. It shows up running the code on Linux.

So that still leaves us option b: the memory at 0x00100170 was not allocated by malloc and therefore cannot be freed, and I forgot option c: the memory at 0x00100170 was freed in a previous call but if you didn't set your links correctly when you deleted it it's still in your list.

Was allocated memory as shown below. First call to free in the whole program, so discard c?

Code:

void addJob(const pid_t pid, const int status, const char* fileName){
	jobs* new = malloc(sizeof(jobs*));
    new->pid = pid;
    new->status = status;
    new->fileName = fileName;
    new->next = job;
    job = new;
    printf("%d added to the list.\n",pid);
}

also, in the debugger you see it points to a struct with all fields initialized, doesn't that imply that memory is allocated to it?

why *new would be better than jobs? Doesn't it cost an extra 'follow'?