Google Interview Question
InternsCountry: United States
Interview Type: Phone Interview
Brilliant!
This doesn't require multithreading or lazy loading (plainly prints a variable). Althought the example is a bit contrived, it shows what may happen: the string you are passing to printf lands somewhere in the constant data section in the executable (like .rodata) and may influence the memory layout (for example, make the '\0' character nearer for a non-terminated string etc.). In this example, the 'p' found by memchr when the printf is uncommented is from "%p" passed to printf!
Such bugs also suffer from "works on my machine" reproduction hardness, because the strings in the read-only section may be reordered and realigned at the compiler's will (and they are most certainly not preserving the order they occur in the source file due to constant string duplicate elimination done by most compilers).
I wish I could +1 it, but some bug in careercup.com just redirects me to my Google account, and when I enter the password nothing happens.
Guess this has to do with memory management at OS level. To make the point clear, we need to understand that once the program reaches machine level the order in which its instructions are to be executed can be messed up. I.e. instruction 3 will be executed first and then instruction 2 and then 4 and so on. However it will be made sure that the end result remains the same.
In our case, the compiler and runtime environment are allocating contiguous memory blocks to each line in function. It ends up creating a substantial memory block in which the function is supposed to operate. However for some reason (say an OS bug or something) the execution falls outside of the allocated block. A printf statement expands the block and runtime error is covered.
Having said that it's important to note that it's possible to avert the error by inserting an assignment statement instead of a printf one. It's just that printf takes more memory allocation and will always cover the worst case scenario.
Multi threading issues? Printf is consuming some time which resolves a multithreading issue?
She didn't mention anything about multi-treading. She asked about different possibilities.
This is an open ended question. There will be more clarity on what is the error information in the runtime error. Could be typecasting, lazy loading or multithreading issue until there is further clarity.
Sorry, I get buffer overflow and multithreading issues, but I am confused about typecasting and lazy loading, at least under the rules of java. I guess if this is C++, virtual pointer offsets might change during typecasting, but I believe they are not supposed to. As for lazy loading, I could see this happening in a dynamic language like groovy in which variables are secretly replaced by getter and setter methods behind the scenes, but this feels like cheating to me.
In addition to the other answers, I've seen something very similar when some part of my code has had undefined bejaviour in it, such as reading a vector value from outside of its range.
As Victor said - this is open-ended question. I can give at least 5 explanations why this can happen.
However, most likely that happens because of the uninitialized variable on one of the future stack frames which is created after printf call.
Without printf unitialized variable has some value (whatever happens to be on the stack). call to the printf modifies the stack changing the future value of that variable. This triggers different runtime behavior.
Could also be the simple case of your code not following the same path due to some Math.random() calculation returning a different result. For instance,
if(Math.random() > 0.5) { return null } else { return true }
So when you added the print statement, it happened to be a different random value and you didn't get the error. So maybe it didn't have anything to do with your action of adding the print statement, event though you think it is related.
Hey guys, check this out. Might not work on some platforms though.
ideone.com/jtkgNj
- PPY January 05, 2015