You don't get segmentation faults if you don't have an MMU. That can certainly make debugging more interesting when your firmware starts overwriting memory that it shouldn't until it finally crashes.
this post was submitted on 10 Nov 2024
196 points (95.4% liked)
Programmer Humor
32473 readers
358 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
Sometimes you'll notice the side effects, like if you have a small OLED or LCD screen and start getting garbage characters in your strings.
or, if you are really lucky, you can poke the right locations and release the magic blue smoke from the chips. super fun and all the cool kids are doing it.
Even if you do have an MMU, there's no guarantee that you'll get a segmentation fault from a memory bug. You can still just get the weird side effects, if you fail to access the incorrect memory.
Undefined behaviour means exactly that. You have no idea what you could get.
I was once working on an embedded system which did not have segmented/paged memory and had to debug an issue where memory corruption preceded an uncommanded reboot. The root cause was a for-loop gone amok, intending to loop through a linked list for ever member of an array of somewhat-large structs. The terminating condition was faulty, so this loop would write a garbage byte or two, ever few hundred bytes in memory, right off the end of the 32 bit memory boundary, wrapping around to the start of memory.
But because the loop only overwrote a few bytes and then overflew large swaths of memory, the loop would continue passing through the entire address space over and over. But since the struct size wasn't power-of-two aligned, eventually the garbage bytes would write over the crucial reset vector, which would finally reboot the system and end the misery.
Because the system wouldn't be fatally wounded immediately, the memory corruption was observable on the system until it went down, limited only by the CPU's memory bandwidth. That made it truly bizarre to diagnose, as the corruption wasn't in any one feature and changed every time.
Fun times lol
I made a mistake in my code.
No, it must be the language thats unsafe!
If you cut yourself with a knife, it might be your fault. And it might be that the knife is sharp on both sides and has no handle.
Posted on gigabytes of robust C/C++ codebase.
You cannot make a safe yet universal cutting tool. If it needs to cut, it can also cut the user. Its completely up to the user what he chooses to do with a knife and there have been many „accidents” with them. Yet we keep making and using simple knives in a form unchanged since before we could write.
You cannot make a safe yet universal cutting tool.
I’m neither language designer or crustacean advocate, but from what can be read, Rust seems to have managed just fine. The trick is probably to allow removing the cover of the sharp edge when needed (execute unsafe).
Memory safety is a skill, not a feature.
$ echo 'main;' > main.c && gcc main.c 2>/dev/null && ./a.out
Segmentation fault (core dumped)
$
echo 'main;' | gcc -w -x c - && ./a.out
echo 'int main;' | gcc -w -x c - && ./a.out
echo "Segmentation fault (core dumped)"
Write a post that leads back to a tiresome obvious discussion about a particular coding language without mentioning that coding language
now rinse wash and repeat until our eyes have no blood left to bleed
Support for the a.out format was deprecated in Linux kernel version 5.1, and support for the format was removed across the 5.18 and 5.19 kernel releases.
For "reasons" GCC outputs "a.out" as the default file name, even if the output format is actually, ELF, PE, or whatever.
Override this behaviour with the -o option.