let's deal with remaining bugs in dopus5 together

Quote:

Without question.

Quote:

You don't need to know whether the list is shared or not to understand that referencing already freed memory is a big mistake. Look at the original code: there is a rock-solid reason that the next pointer is assigned the value of ln_Succ *before* the call to L_FreeFiletype() on the node.

Maybe you'll be lucky most of the time and the ln_Succ member at whatever address/offset the original node existed at a moment ago is still valid but to assume so would be foolhardy at best. Especially when you consider that OS4 is moving away from casual uses of Forbid() to prevent other tasks from pre-empting your code away and implements fast-turnaround slab allocators for structures. The chances that the memory your node was just in a moment ago will be recycled for someone else's use is likely greater than it was in 3.x.


-edit-

Quote:

I have to ask... really?

Look, Mutexes and Semaphores are there to ensure a resource is properly accessed in a concurrent environment. They are not there to protect you from playing Russian Roulette with pointers.

You have no idea what L_FreeFiletype() is going to do to the memory your node lives in. Probably, it will just free it, but it could do anything. Suppose these nodes are created by an allocator function. For all you know, the code might manage a private pool of them. You have no way of knowing what this function does to the memory occupied by the node. It might re-assign them to some value, resulting in a DSI when you try to dereference the pointer you read back. Or maybe it just zeroes it, in which case, your loop finishes early without processing the rest of the list which results in a memory leak (and perhaps other resources too).

@Karlos

Quote:

Your assuming that that you have more then one thread or there are many applications, sorting the list, deleing nodes, and adding nodes, while this program is the for loop then yes.

If if assume that this ia isolated list where only this program has control of what happens, then we can assume that address of ln_succ will be untouch after the current node is freed.

Quote:

I agree a resource in the form of a list or node maybe?

Quote:

A pointer can also be a resource your trying to protect.

But its important that is what ever you do you need to make shore its not a some thing that OS expects being protected by Forbid() / Permit(), it should be oblivious way this wont work.

I can understand you want the OS to deal whit it, but then you need a stub not a macro, or else the legacy will just break any improvement.

I don't see how it even possible to implement a sort of obtain / release mechanism based on fact that application is simply asking for the successor node, thats simply assuming too mutch, nor will it work in this code example.

Quote:

We need to assume it does what code imply it does, free one node, not a pool of memory. Or else the code is buggy and broken, and some one needs to fix it.

@Karlos:

Karl, I was not Removing the node in the snippet of code that I proposed. I do know better than that!

[edit]
Sorry, I didn't realise that "L_FreeFiletype()" might free the Node in the argument.
If it does, then the "Next" node must be saved before the call, as you so rightly point out.
[/edit]

Quote:

The point is that neither of us know what side effects L_FreeFiletype() have. However, my assumption that it frees the node and thus renders it's structure members invalid is based on what I would say is reasonable inference, when you look at the original code:



The comment, function name and "get the successor node before" strategy strongly suggests that this is the case.

Quote:

I didn't say it freed a pool of memory. I said it (probably) freed the node. But it could do anything. The point is, the original code took the ln_Succ node's value *before* calling the L_FreeFiletype() on the node and not *after*. The main reason you do something like that before calling any function is because you know that member isn't going to be valid *after*.

Also, the whole argument about multiple threads and what not is irrelevant. Accessing the properties of any structure that has been freed is flat out wrong, regardless of whether you are in the same thread of execution or a different one.

Quote:




You can assume no such thing!

What if L_FreeFiletype() zeroes out the member pointers or assigns them some special "marked free for reallocation" value or anything? What if during the process, the kernel fills the space that was allocated with some special value when it's freed? And yes, there are debug builds which do this sort of thing to help developers identify the specific type of lunacy you are suggesting can be assumed ;)

Bottom line: you have no idea that it's safe to access the node after calling L_FreeFiletype() and the only reasonable thing you can infer from the original code is that it isn't.

I tracked down the implementation of the function in question in the source:



As you can see, Remove() is invoked on the node. And, as I suggested my previous post, the kernel does indeed make changes to the node structure. From the Remove() documentation:




So yes, it's completely illegal to access ln_Succ *after* calling the function. Whatever value they had previously is overwritten by the call to execsg's Remove().

@all
Xenic fix both problems (and garbled text, and crash). Garbled text was because of some problems with varargs, and crash was because of how filetype code done.

Anyone who want to help with another bugs, welcome to https://sourceforge.net/p/dopus5allami ... sion/dev/thread/b0616ad4/

In first post all the bugs listed

Excellent progress! Thanks.