l lang="en" op="item"> I wonder about the technical knowledge of this person who's writing articles abo... | Hacker hyakkendana-hashigozake.com
*
Hacker hyakkendana-hashigozake.com new | past | comments | ask | show | jobs | submit login



You are watching: Explain the significance of dead beef

I wonder about the technical knowledge of this person who"s writing articles about hiring technical people."Explain the significance of ‘dead beef"" is a perfectly valid, if somewhat unimaginative, technical question.

Frankly, 0xdeadbeef is a rather bad value for a pointer poison: It doesn"t have enough leading zeros to be caught in unmapped area used to catch null pointer access (it has a high change of being a valid kernel address on linux if you have about 700mb of ram). And there are not enough zeros at the end to still recognize it if the access is to a offset within the array/structure (as it usually happens).Not catching the usage of a poisoned pointer on first access creates enormous amounts of fun - normally preventing any meaningful analysis of dumps.

Agreed - not only do I find "DEAD BEEF" as a rather gross concept, but there are technical flaws, as you point out. I personally prefer the simple, form-matches-function 0x0000DEAD. Yup, that pointer"s dead baby!

No, it"s not. It"s a trivia question. Nobody uses such techniques any more because looking at raw memory dumps is not the right way to debug these days.

Using a "magic marker" like this doesn"t imply looking at a raw memory dump (which, however, is still needed in several places Google is involved e.g., kernel hacking, embedded devices). For example, I used it myself when debugging an issue where our processes morphed into un-killable zombies. I was dealing with crash dumps, where I was walking through the process list in the kernel (it"s a doubly linked list) in crash/gdb (looking at kernel memory dump obtained via netdump from a production server that manifest this condition) so I could find a process that has acquired a specific lock to test whether a theory that I had was true. I wasn"t (and still am not) at Google and I don"t even claim to have any expertise in actual kernel development: it was a bug a customer was experiencing and it needed to be fixed.Lastly (and I am completely going on a limb here, without any concrete information), this could also be used to gauge team/culture fit Google. This is a good way to see if you"ll be a fit for a team that spends a huge amount of time finding and fixing low-level bugs: it"s fun to read about infrastructure that Google has built, but the actual process of building it may be very frustrating to some. Not being a fit for such a group doesn"t imply rejection, it could simply mean you"re brought back to a different round with another set of people.

If you want conformity that"s fine. What would you think if your company instituted a very specific dress code? Requiring specific trivial knowledge is just as restrictive and constraining.If you want to find engineers with talent then you need to do a lot more leg-work in plumbing their knowledge, experience, and skill than merely ticking off a checklist of shibboleths.P.S. Personally I love hacker jargon and lore, I like knowing about scratch monkeys, core memory, the usenet cabal, and even 0xDEADBEEF, but I wouldn"t take ignorance of those things to translate to ignorance of engineering fundamentals or of passion in software development.
> If you want conformity that"s fine. What would you think if your company instituted a very specific dress code? Requiring specific trivial knowledge is just as restrictive and constraining.It"s not about hacker folklore, it"s about a debugging technique.No one implies that this question is asked of every candidate. That"s why these lists are useless. It"s also not the way I"d ask a question about memory markers (I"d ask them about how they go about debugging such a problem and how the tools they use e.g., gdb and valgrind work), but it"s a fair question to ask those claiming experience with or interest in low-level development much like it"s fair to ask candidates who claim experience with data mining what the kernel trick is (...but it would be misleading to ask a Linux kernel hacker that question as that would mean something else to him, much as dead beef would mean something else to a data mining guru).
Keep in mind, I"m responding specifically to the idea that " the significance of ‘dead beef"" is a valid interview question. Have you done a survey of memory debugging experts to determine how common knowledge of "dead beef" is?It"s not a knowledge question, it"s a trivia question. A shibboleth. It is neither a necessary nor sufficient pre-condition for knowledge of memory debugging techniques and it probably has about as much correlation with them as asking whether they have read The Lord of the Rings.
> It is neither a necessary nor sufficient pre-condition for knowledge of memory debugging techniques and it probably has about as much correlation with them as asking whether they have read The Lord of the Rings.It"s a hexadecimal number, that should be quite obvious. It"s a noteable and easy to notice one. Others may have used a different one (I used 0x12341234 for the task as others have used 0xdeadbeef) but it should be obviously what you"d use it for.Is it one of the better questions? No. Is it merely a shibboleth or a piece of trivia? When asked to low-level hackers, no.
When shorn of hexadecimal connotation as in the original question what value is there to it? If I ask someone verbally "what is the significance of dead beef" should I put any value in their either having already learned about 0xDEADBEEF or in their ability to appreciate that it could be a 32-bit word aligned hex value?If someone were to change the question to "what is the significance of bad food?" would it be considered equally valuable?
O is not a hexadecimal number- even if it was "BAD F00D" it still wouldn"t be a full 32-bit word- it"s also not use by existing libraries (libgmalloc)cafe babe, dada dada would just as well as dead beefIn short, either you are familiar with magic numbers or you"re not. If you"re not, you"re certainly not qualified to work on anything really low-level and may not be qualified to do C/C++ development in userland either (without strong evidence to the contrary).
No it"s not. If you don"t know about magic numbers you don"t know how the BIOS loads the kernel into memory. Period.
+1 for a well-put argument.However, I admit to asking a lot of trivia questions when interviewing candidates at Apple, partly as a culture fit, and partly because I could use them to segue into a chain of questions that dealt with the consequences of seemingly innocuous design decisions made by engineers long ago. This was something my group had to learn to foresee and deal with when we thought bad things would happen.One of these questions had to do with 0xCAFEBABE.That said, getting the trivia part right was a +1, and not knowing the info was a +0, so no harm if the job candidate didn"t know it.I"d also use them as a shortcut to validating their experience in an area. Again, a +0 if they didn"t know the trivia, but if they do, I can move on to a different line of questions.
I"d also use them as a shortcut to validating their experience in an areaThat seems very dangerous. I, for example, know about DEADBEEF and CAFEBABE as hacker trivia, yet have close zero experience in actually using those techniques for debugging real world problems.
The "right way" depends on the task at hand and the tools you have at your disposal. For any type of low-level work, being able to view, understand, and observe regions of memory is pretty much essential.
If the candidate is bragging about the time he saved the day with raw memory debugging, I"d start with this question to confirm.
strlen Again, some of the questions are absolutely 100% FAKE.So if some questions (like the "why are manhole covers round") are definitely fake, and others seem very weird (like the dead beef one), isn"t is more likely that that question is fake too?
> So if some questions (like the "why are manhole covers round") are definitely fake, and others seem very weird (like the dead beef one), isn"t is more likely that that question is fake too?It may sound fake to you, for a specific team you interviewed people for. But, it"s an entirely reasonable question to ask for someone who claims low-level experience for a team that actually does low-level work. Use a product your ex-employer has built to search for "0xdeadbeef" and you"ll see this technique is not just a piece of esoterica.There are many kinds of software engineers: a low-level hacker may just be as puzzled by "support vector machines" (why do they need our support?!) as you are by 0xdeadbeef.


See more: This Bike Is A Pipe Bomb Songs, Albums, Reviews, Bio & More, This Bike Is A Pipe Bomb Austin Shows On Do512

yeah, I"ve read this blog post before, and this bit has always stunk to me.The pattern might be 0xDADADADA, 0xCAFEBABE, or 0xDEADBEEF. But it seems perfectly reasonable to ask what one might use this for. In fact, you"ll find 0xDEADBEEF in the man page for libgmalloc.(and all of the replies are about "raw memory" debugging... wtf)