Related
This is a tricky C question asked in interview: Write a program that does nothing, not even taking up memory.
Is it possible to do so?
All programs use memory. When you run the program, the OS will set up an address space for the program, copy its arguments into its process space, give it a process ID and a thread, give it some file descriptors for I/O, etc. Even if your program immediately terminates you still use up this memory and CPU time.
No its not possible. The code and stack must go somewhere and that will, nearly always, be in memory.
Ignoring that surely its pretty easy to just write an application that exits straight away.
your response should be along the lines of enquiring as to 'why' you'd want to do such a thing. this would show a latitude for thinking beyond the question.
On the surface the question seems to have a simple answer: "No, it can't be done." #templatetypedef has given some reasons.
But perhaps the point of the question is to see how you address it. You might get "marks" for asking "what kind of memory" or for observing some of the points that #templatetypedef made. Or for showing the empty main() method given by #Mihran Hovsepyan and then explaining that some memory will be involved even in this minimal case.
Although there will be some memory allocated by OS when you launch a program, most people don't know that main() is not the real program entry point. mainCRTStartup is, at least on Windows console app. If you create a program with real entry point you will avoid heap initialization routines, command argument parsing, global variable initialization and so on.
So, in some sense, you can make a program that avoids heap management and stuff. But OS will still read it into memory.
See: http://www.catch22.net/tuts/minexe
Empty program is a program, isn't it?
Below is my no resource use program :)
Also note that. Strictly speaking, a program really don't consume any resource until OS load it and make it run. When this happen we call it a Process.
The correct answer is that it's implementation-specific. An implementation could support null programs and the execve (or equivalent) mechanism could perform the equivalent of _Exit(0) when it encounters one, but in practice it doesn't.
I've got a buffer overrun I absolutely can't see to figure out (in C). First of all, it only happens maybe 10% of the time or so. The data that it is pulling from the DB each time doesn't seem to be all that much different between executions... at least not different enough for me to find any discernible pattern as to when it happens. The exact message from Visual Studio is this:
A buffer overrun has occurred in
hub.exe which has corrupted the
program's internal state. Press
Break to debug the program or Continue
to terminate the program.
For more details please see Help topic
'How to debug Buffer Overrun Issues'.
If I debug, I find that it is broken in __report_gsfailure() which I'm pretty sure is from the /GS flag on the compiler and also signifies that this is an overrun on the stack rather than the heap. I can also see the function it threw this on as it was leaving, but I can't see anything in there that would cause this behavior, the function has also existed for a long time (10+ years, albeit with some minor modifications) and as far as I know, this has never happened.
I'd post the code of the function, but it's decently long and references a lot of proprietary functions/variables/etc.
I'm basically just looking for either some idea of what I should be looking for that I haven't or perhaps some tools that may help. Unfortunately, nearly every tool I've found only helps with debugging overruns on the heap, and unless I'm mistaken, this is on the stack. Thanks in advance.
You could try putting some local variables on either end of the buffer, or even sentinels into the (slightly expanded) buffer itself, and trigger a breakpoint if those values aren't what you think they should be. Obviously, using a pattern that is not likely in the data would be a good idea.
While it won't help you in Windows, Valgrind is by far the best tool for detecting bad memory behavior.
If you are debugging the stack, your need to get to low level tools - place a canary in the stack frame (perhaps a buffer filled with something like 0xA5) around any potential suspects. Run the program in a debugger and see which canaries are no longer the right size and contain the right contents. You will gobble up a large chunk of stack doing this, but it may help you spot exactly what is occurring.
One thing I have done in the past to help narrow down a mystery bug like this was to create a variable with global visibility named checkpoint. Inside the culprit function, I set checkpoint = 0; as the very first line. Then, I added ++checkpoint; statements before and after function calls or memory operations that I even remotely suspected might be able to cause an out-of-bounds memory reference (plus peppering the rest of the code so that I had a checkpoint at least every 10 lines or so). When your program crashes, the value of checkpoint will narrow down the range you need to focus on to a handful of lines of code. This may be a bit overkill, I do this sort of thing on embedded systems (where tools like valgrind can't be used) but it should still be useful.
Wrap it in an exception handler and dump out useful information when it occurs.
Does this program recurse at all? If so, I check there to ensure you don't have an infinite recursion bug. If you can't see it manually, sometimes you can catch it in the debugger by pausing frequently and observing the stack.
I have built a plain C code on Linux (Fedora) using code-sorcery tool-chain. This is for ARM Cortex-A8 target. This code is running on a Cortex A8 board, running embedded Linux.
When I run this code for some test case, which does dynamic memory allocation (malloc) for some large size (10MB), it crashes after some time giving error message as below:
select 1 (init), adj 0, size 61, to kill
select 1030 (syslogd), adj 0, size 64, to kill
select 1032 (klogd), adj 0, size 74, to kill
select 1227 (bash), adj 0, size 378, to kill
select 1254 (ppp), adj 0, size 1069, to kill
select 1255 (TheoraDec_Corte), adj 0, size 1159, to kill
send sigkill to 1255 (TheoraDec_Corte), adj 0, size 1159
Program terminated with signal SIGKILL, Killed.
Then, when I debug this code for the same test case using gdb built for the target, the point where this dynamic memory allocation happens, code fails to allocate that memory and malloc returns NULL. But during normal stand-alone run, I believe malloc should be failing to allocate but it strangely might not be returning NULL, but it crashes and the OS kills my process.
Why is this behaviour different when run under gdb and when without debugger?
Why would malloc fails yet not return a NULL. Could this be possible, or the reason for the error message I am getting is else?
How do I fix this?
thanks,
-AD
So, for this part of the question, there is a surefire answer:
Why would malloc fails yet not return a NULL. Could this be possible, or the reason for the error message i am getting is else?
In Linux, by default the kernel interfaces for allocating memory almost never fail outright. Instead, they set up your page table in such a way that on the first access to the memory you asked for, the CPU will generate a page fault, at which point the kernel handles this and looks for physical memory that will be used for that (virtual) page. So, in an out-of-memory situation, you can ask the kernel for memory, it will "succeed", and the first time you try to touch that memory it returned back, this is when the allocation actually fails, killing your process. (Or perhaps some other unfortunate victim. There are some heuristics for that, which I'm not incredibly familiar with. See "oom-killer".)
Some of your other questions, the answers are less clear for me.
Why is this behaviour different when run under gdb and when without debugger?It could be (just a guess really) that GDB has its own malloc, and is tracking your allocations somehow. On a somewhat related point, I've actually frequently found that heap bugs in my code often aren't reproducible under debuggers. This is frustrating and makes me scratch my head, but it's basically something I've pretty much figured one has to live with...
How do i fix this?
This is a bit of a sledgehammer solution (that is, it changes the behavior for all processes rather than just your own, and it's generally not a good idea to have your program alter global state like that), but you can write the string 2 to /proc/sys/vm/overcommit_memory. See this link that I got from a Google search.
Failing that... I'd just make sure you're not allocating more than you expect to.
By definition running under a debugger is different than running standalone. Debuggers can and do hide many of the bugs. If you compile for debugging you can add a fair amount of code, similar to compiling completely unoptimized (allowing you to single step or watch variables for example). Where compiling for release can remove debugging options and remove code that you needed, there are many optimization traps you can fall into. I dont know from your post who is controlling the compile options or what they are.
Unless you plan to deliver the product to be run under the debugger you should do your testing standalone. Ideally do your development without the debugger as well, saves you from having to do everything twice.
It sounds like a bug in your code, slowly re-read your code using new eyes as if you were explaining it to someone, or perhaps actually explain it to someone, line by line. There may be something right there that you cannot see because you have been looking at it the same way for too long. It is amazing how many times and how well that works.
I could also be a compiler bug. Doing things like printing out the return value, or not can cause the compiler to generate different code. Adding another variable and saving the result to that variable can kick the compiler to do something different. Try changing the compiler options, reduce or remove any optimization options, reduce or remove the debugger compiler options, etc.
Is this a proven system or are you developing on new hardware? Try running without any of the caches enabled for example. Working in a debugger and not in standalone, if not a compiler bug can be a timing issue, single stepping flushes the pipline, mixes the cache up differently, gives the cache and memory system an eternity to come up with a result which it doesnt have in real time.
In short there is a very long list of reasons why running under a debugger hides bugs that you cannot find until you test in the final deliverable like environment, I have only touched on a few. Having it work in the debugger and not in standalone is not unexpected, it is simply how the tools work. It is likely your code, the hardware, or your tools based on the description you have given so far.
The fastest way to eliminate it being your code or the tools is to disassemble the section and inspect how the passed values and return values are handled. If the return value is optimized out there is your answer.
Are you compiling for a shared C library or static? Perhaps compile for static...
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 3 years ago.
Improve this question
So I have a C program. And I don't think I can post any code snippets due to complexity issues. But I'll outline my error, because it's weird, and see if anyone can give any insights.
I set a pointer to NULL. If, in the same function where I set the pointer to NULL, I printf() the pointer (with "%p"), I get 0x0, and when I print that same pointer a million miles away at the end of my program, I get 0x0. If I remove the printf() and make absolutely no other changes, then when the pointer is printed later, I get 0x1, and other random variables in my structure have incorrect values as well. I'm compiling it with GCC on -O2, but it has the same behavior if I take off optimization, so that's not hte problem.
This sounds like a Heisenbug, and I have no idea why it's happening, nor how to fix it. Does anyone who has dealt with something like this in the past have advice on how they approached this kind of problem? I know this may sound kind of vague.
EDIT: Somehow, it works now. Thank you, all of you, for your suggestions.
The debugger told me interesting things - that my variable was getting optimized away. So I rewrote the function so it didn't need the intermediate variable, and now it works with and without the printf(). I have a vague idea of what might have been happening, but I need sleep more than I need to know what was happening.
Are you using multiple threads? I've often found that the act of printing something out can be enough to effectively suppress a race condition (i.e. not remove the bug, just make it harder to spot).
As for how to diagnose/fix it... can you move the second print earlier and earlier until you can see where it's changing?
Do you always see 0x1 later on when you don't have the printf in there?
One way of avoiding the delay/synchronization of printf would be to copy the pointer value into another variable at the location of the first printf and then print out that value later on - so you can see what the value was at that point, but in a less time-critical spot. Of course, as you've got odd value "corruption" going on, that may not be as reliable as it sounds...
EDIT: The fact that you're always seeing 0x1 is encouraging. It should make it easier to track down. Not being multithreaded does make it slightly harder to explain, admittedly.
I wonder whether it's something to do with the extra printf call making a difference to the size of stack. What happens if you print the value of a different variable in the same place as the first printf call was?
EDIT: Okay, let's take the stack idea a bit further. Can you create another function with the same sort of signature as printf and with enough code to avoid it being inlined, but which doesn't actually print anything? Call that instead of printf, and see what happens. I suspect you'll still be okay.
Basically I suspect you're screwing with your stack memory somewhere, e.g. by writing past the end of an array on the stack; changing how the stack is used by calling a function may be disguising it.
If you're running on a processor that supports hardware data breakpoints (like x86), just set a breakpoint on writes to the pointer.
Do you have a debugger available to you? If so, what do the values look like in that? Can you set any kind of memory/hardware breakpoint on the value? Maybe there's something trampling over the memory elsewhere, and the printf moves things around enough to move or hide the bug?
Probably worth looking at the asm to see if there's anything obviously wrong there. Also, if you haven't already, do a full clean rebuild. If the definition of the struct has changed recently, there's a vague change that the compiler could be getting it wrong if the dependency checking failed to correctly rebuild everything it needed to.
Have you tried setting a condition in your debugger which notifies you when that value is modified? Or running it through Valgrind? These are the two major things that I would try, especially Valgrind if you're using Linux. There's no better way to figure out memory errors.
Without code, it's a little hard to help, but I understand why you don't want to foist copious amounts on us.
Here's my first suggestion: use a debugger and set a watchpoint on that pointer location.
If that's not possible, or the bug disappears again, here's my second suggestion.
1/ Start with the buggy code, the one where you print the pointer value and you see 0x1.
2/ Insert another printf a little way back from there (in terms of code execution path).
3/ If it's still 0x1, go back to step 2, moving a little back through the execution path each time.
4/ If it's 0x0, you know where the problem lies.
If there's nothing obvious between the 0x0 printf and the 0x1 printf, it's likely to be corruption of some sort. Without a watchpoint, that'll be hard to track down - you need to check every single stack variable to ensure there's no possibility of overrun.
I'm assuming that pointer is a global since you set it and print it "a million miles away". If it is, lok at the variables you define on either side of it (in the source). They're the ones most likely to be causing overrun.
Another possibility is to turn off the optimization to see if the problem still occurs. We've occasionally had to ship code like that in cases where we couldn't fix the bug before deadlines (we'll always go back and fix it later, of course).
I have often heard that C can crash spectacularly. Recently I got my first taste of this when a function I expected to return a string instead returned little happy faces. Since then I have been being more careful with initializing pointers and mallocing memory for arrays. Still, though, I have trouble believing that a program could crash THAT badly...
I guess it would depend on the scope of the program though? I mean, if a bug in a program that dealt with your fan copied happy faces into some important space in memory...?
My question is, how much myth is there in the world of spectacular C crashes? Can I get some concrete examples of dangerous things that one ought to avoid?
z.
http://xkcd.com/371/
http://blog.raamdev.com/category/technology/programming/cc
http://en.wikipedia.org/wiki/Segmentation_fault
I think it was probably worse way back in the pre-virtual memory days when you could trash other processes memory, but nowadays the worst that can happen is really just crashing your own program. Usually via segmentation faults from bad pointers.
That excludes of course blowing things up by misusing system resources - you can do that in any language.
Back when I was learning to program C++, it was on a Mac running system 7 or 8 I don't remember which. Anyway, it had no protected virtual memory so a lot of mistakes like leaving a dangling pointer or a buffer overrun would cause the whole computer to crash. I recall that when Apple first announced they were going to create a new OS which had protected memory space at Macworld or something, they showed the source code for a program:
while (true)
*(int *)i++ = 1;
And when they ran the program and just the program terminated, and not the whole machine (it had a message like "You do not need to restart your computer") the whole room full of developers apparantly burst into applause. Anyway, obviously not having protected memory really made programming C or C++ really tough because of the increased severity of the crash.
Nowadays it is not such a big deal unless you are programming something that runs at supervisor level, you do not have the ability to crash the OS.
The worst thing that happened to me were memory corruptions which did not cause a crash immediately, but after a while.. making it so hard to detect.. argh
The operating system prevents most horrible issues these days. The worst I've ever done is hard-lock the machine (just had to reboot by holding down the power button) and scramble a few files.
All depends what resources you're accessing, really. If you're writing files, there are some ways directory structures can get tangled that used to confuse system utilities, but most of those problems have been fixed. If you're doing something as root, well, then you can sure make a mess because many more system files are writeable. If you're using the network, there's a lot of stuff that can go moderately wrong, but not much more than using up too much bandwidth is likely. Of course, a few years of programming and you'll see all sorts of unlikely things.
For the most part though, it's ok to experiment and play around. These days the systems are resilient enough that you won't make a mess that's too hard to get back out of. The operating system keeps each program to its own piece of memory, and disallows access to change critical systems unless you're administrator/root. Your garden variety dangling pointer may print funny things or crash your program, but it isn't going to destroy a modern computer.
From a comment in another reply: "I am using the Nintendo DS to run them"
Ok, that matters! (First: Awesome idea! Sounds like fun.) Coding for something like that is not the same in terms of what can go wrong as most coding for a desktop computer. A brief look at the documentation for libnds and some tutorials on Nintendo DS programming indicates to me that there's no OS to speak of. So, I have no idea how much you could do with a stray pointer, probably a lot. Possibly something damaging. It might be a good idea to hunt for people who've done programming for that platform before, see what they have to say.
Here is a quick snippet from Henry Spencer's "Ten Commandments for C Programmers":
Commandment #2 - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.
Clearly the holy scriptures were mis-transcribed here, as the words should have been ``null pointer'', to minimize confusion between the concept of null pointers and the macro NULL (of which more anon). Otherwise, the meaning is plain. A null pointer points to regions filled with dragons, demons, core dumps, and numberless other foul creatures, all of which delight in frolicing in thy program if thou disturb their sleep. A null pointer doth not point to a 0 of any type, despite some blasphemous old code which impiously assumes this.
For those who are not familiar with C, I think the best written concise introduction to C is done by "The Ten Commandments for C Programmers (Annotated Edition)" by Henry Spencer. The way it is written really gets across to the reader the dangers of C ... while at the same time being funny ( which means the reader will actually pay attention more ).
=========================
Personally... C doesn't crash that badly when you are doing desktop development because you have the luxury of seg-faulting. Seg-faults are when the OS sees you trying to REALLY F' things up and it says "hey! you aren't allowed there" and stops the process.
When you are doing embedded C development... that is when you get the REALLY spectacular crazy stuff... i.e. they REQUIRE you to power-cycle 99.9% of the time. Like this one time where the code somehow messes up my call stack... and then you are executing some random other function... and then the ISR somehow is still going... and it takes 2 weeks to fix that kind o bug.
Well, if you're writing kernel code, sometimes you can overwrite system critical bits of memory, such as interrupt vectors, global descriptor tables, process tables, causing all sorts of fun stuff!
C itself can't crash anything. Sloppy programming can crash everything.
The "happy faces" are an indication that your code corrupted memory. The only thing C had to do with that is the fact that you chose to use it. (And the fact your OS allowed it to happen is surprising - are you still running a version of DOS?)
Nowadays is kind of hard making C crash that hard (unless you are coding an OS Kernel or something like that).
Back in the DOS/Win95/Win98 days, you could make a C program chash really, really badly. I used to get this a lot:
Whenever I had a dangerous pointer operation which messed with the memory, I got a character based screen full of all sorts of characters, in different colors, some of them, blinking!!! I guess the operations messed someway with Video Memory.
But today, since processes run within safe kernels, the worst you'll get if your process going away.
prior to protected-memory architectures, most of the jump vectors used by the operating system were stored in the zero page of memory (addresses starting at zero)
so writing to memory locations in the zero page - easily done with null/bad pointers - would change the operating system's jump vectors, causing all kinds of bizarre crash behavior - everything from locked-out keyboards and blinking video screens full of garbage to hard drive light flashing frenzy, blue screen of death, rebooting, etc.
[coding in assembly language was even more fun]
If your code is running on a remotely modern OS, you can't copy happy faces into random points in memory. You can crash as much as you want, and it will just result in the termination of your process.
The closest you can come to actually messing up your system is abusing processor/memory/disk resources, or spawning so many subprocesses that the OS runs out of PIDs (if it's still using a 32-bit value to store those).
There was a computer, the Commodore PET 4032 (aka the "Fat 40") where it was actually possible to permanently burn out the video chip if you poked the wrong value into the wrong part of memory. You can imagine that if there had been a C compiler on that machine, a wild pointer could actually do irreparable physical damage to the computer.
Back in the DOS days I actually over-wrote bios information. Had to get a tech to fix it. My first home computer - 286. Unbootable after a day or two.
On any OS with protected memory the worst that can happen is that your process crashes. Now if your process happens to be part of the kernel or a kernel extension then you can obviously crash the whole OS but that is the worst you can do.
However, really this the same with many other languages (for example in C deference a null pointer, in java use an object reference set to null, both will crash your process).
So, I believe with protected memory, C can't do any more damage than any other Language (unless your process is part of the OS ;))
Well, back in the DOS days, I managed to over-write part of the boot sector - nothing like rebooting to find "OS Not Found" or whatever the message was.
You learn the hard way to be very, very careful writing to disk after that...
C lets you deal with the machine pretty close to directly. How spectacularly it can crash is a function of what the machine can do.
So: A user mode process without special privileges in a nice modern operating system won't really do that much. But you have software all over the place. Think about the software controlling the braking systems in a train. Think about the software running the emergency intercom when someone really needs help. Think about the software running the signs on a busy highway. Think about the software running a guided missile system.
There is software all over the place these days. A lot of it is written in C.
Back when I was writing the Win98 drivers, the BSOD haunted everyone. I remember the following mistake I made
typedef struct _SOME_TAG_ {
int nSomeVar;
int nSomeMore;
...
} MYSTRUCT, *PMYSTRUCT;
....
PMYSTRUCT pMyStruct;
// And I use this structure without allocating any memory ;-)
pMyStruct->nSomeVar = 0;
And the driver crashes were so horrible but we had a SoftICE from Numega, Though it is only 10 years ago .. I feel its like ages back
Back in college I was tasked on creating a multi-threading proxy.
From time to time, the proxy wasn't responding any of the resources the page pulled. The code causing the issue:
Some code with overflow issues, that used variables near a file handler. Before knowing what was happening, I found it really weird that moving the file handler declaration "fixed" the issue, lol.
Ps. check this one (not in c, but a good story :)): http://trixter.wordpress.com/2006/02/02/computing-myth-1-software-cannot-damage-hardware/
If the software in question is running on a PC, it may "merely" bring down your computer.
If, however, it's controlling the operation of the engine in your car -- or worse, the ABS -- it won't just be the software that crashes...
A crash is not the worst thing that can happen.
I read about an old Unix file compression program (you know, like Zip) that didn't check the return value from fclose. Yes, fclose can return an error. Output to a file is normally buffered, so even if a call to fwrite or putc seems to work, and returns OK, the data may still be in a buffer, waiting to be written. When fclose is called, any unwritten data is flushed, and this may fail, since (for example) the disk may be full. And since the compression program was usually run just because the disk was nearly full, this happened rather often. So the program silently truncated the new, compressed file, the original uncompressed file was removed, and the next year or so when someone tried to uncompress the file, the end was missing!
I think this is a good example of why throwing exceptions can be good thing.