0xdeadbeef = NULL?

I was cleaning up my memory, specifically, free-ing out my file handle objects. Basically I have an array of size OPEN_MAX, each element of which stores a pointer to my file handle struct. Initially I start out with all NULLs in the array. (with and without doing so explicitly). In my sys_close logic, when the reference count of a handle is 0, I deallocate the file handle object and set a NULL at that index in my file table.

However, in subsequent calls to open, I observe that a 0xdeadbeef has been written into the file table instead of a NULL. Thus, my NULL-checking logic fails. Is this something I should be manually checking for?

The bigger picture: All tests except forktest-stability fail. Essentially, the first instance of p testbin/forktest passes in sys161. Subsequent invocations of p testbin/forktest fail because my file table contains deadbeefs.

You can probably get away with manually checking for 0xdeadbeef too whenever you check for NULL.

This is a symptom of a deeper problem. kmalloc writes 0xdeadbeef to areas of memory when they are freed as a debugging technique. So this implies that your file table somehow overlaps with some other allocation that you’ve made. So this is a problem.

You should never check for 0xdeadbeef anywhere—again, it’s entirely a debugging approach.

I had a similar problem with Kfree
I thought it was a synchronicity error but the real problem was I accidentally called Kfree two different places in the code.

Calling kfree twice was causing us the problem.

I hope that helps!

1 Like