Comments for DevJournal - Finished the switch to dynamic allocation and managed memory at http://freaklabs.org , comment 1 to 4 out of 4 comments http://freaklabs.org Fri, 12 Mar 2010 18:11:25 +0100 FeedCreator 1.7.2 http://freaklabs.org/index.php/Blog/FreakZ/DevJournal-Finished-the-switch-to-dynamic-allocationand-managed-memory.html#comment-185 Thanks for the flashback. It's nice to know that we're rehashing problems that were solved in 1985 :) I will start to refer to the pointer to the memory pointer as a handle. - Akiba Wed, 25 Feb 2009 09:49:13 +0100 http://freaklabs.org/index.php/Blog/FreakZ/DevJournal-Finished-the-switch-to-dynamic-allocationand-managed-memory.html#comment-184 At least that is what Apple called it in the original Macintosh toolbox (1984-). On the Mac a handle could be locked before dereferencing, then the pointer used in a section of code that called other toolbox functions that might shift memory around. The handle was then supposed to be unlocked to minimize "heap fragmentation". Not locking the handle was a frequent cause of the amusing Mac bomb dialog box. - David Kopf Wed, 25 Feb 2009 04:48:19 +0100 http://freaklabs.org/index.php/Blog/FreakZ/DevJournal-Finished-the-switch-to-dynamic-allocationand-managed-memory.html#comment-112 Hi Adam. No problem. It was actually my mistake. I had run into the MMEM_PTR macro previously when I was reading through the code, but at that time, I didn't fully understand the behavior of the code. Now that you refreshed my memory, I could see why its needed. I'll be modifying the code to access the data elements through it. Hopefully, that will make things more robust and I won't need to run the risk of some later mod creating a dangling pointer. BTW, congrats on all the activity at SICS recently. Sounds like you guys must be pretty busy. - Akiba Sun, 26 Oct 2008 11:41:37 +0100 http://freaklabs.org/index.php/Blog/FreakZ/DevJournal-Finished-the-switch-to-dynamic-allocationand-managed-memory.html#comment-111 Very nice post explaining how the mmem module works! Much better than the actual 'documentation' in the mmem module... ;) But, one very important point that needs to be raised: the MMEM_PTR() macro is the [b]only[/b] way to access the pointer to the actual memory block. The pointer to the actual memory should [b]never[/b] be explicitly accessed through the struct. Also, the pointer should never be stored somewhere else. By always using the MMEM_PTR() macro to access the memory, the problem with the moving addresses should not occur - or at least this was the idea behind the mmem module :) The problematic case should be rewritten like this: mem_ptr = list_head(rte_tbl); // grab the first mem pointer from the route table /* rte_entry = mem_ptr->mmem_ptr.mem_block_ptr; never de-reference and store the mem pointer like this */ some_random_func(); // a memory block gets freed somewhere in here next_hop = ((struct tbl *)MMEM_PTR(mem_ptr))->next_hop; /* this is the way to access the memory pointed to by mem_ptr - this works even if a memory block was freed in some_random_func(). */ Sorry if this was not clear from the module's documentation - the documentation for this module is known to be bad :'( - adam Sat, 25 Oct 2008 17:23:37 +0100