Strolling off the edge
-
My last three major problems in my code involved buffer overruns. These are fun on the ESP32 or other platforms without memory protection because you don't crash when the Bad Thing(TM) happens. You crash in the aftermath as a consequence, by for example, trying to execute an illegal instruction because your data overwrote your code. Because of that, even *if* your stack dump isn't corrupt you still won't get much in the way of a hint as to where the actual error is. The bottom line is you get to debug it blind. I solved the last three times this happened, and it's making me a better troubleshooter. Damn it's difficult though.
To err is human. Fortune favors the monsters.
-
Reminds me of the good old days when one of the operators would come in to the office with a 300-500 page hexdump of the operating system, because it crashed.
Richard MacCutchan wrote:
Reminds me of the good old days
I was thinking it reminded me of the little less old days (1992) when I was learning C/C++ pointers on a machine running DOS 5.x and Win 3.1 It was the same then. The machine or app didn't immediately crash or anything. Just kept going until that memory was used by something else. A lot of the crashing now is caused because of DEP (Data Execution Prevention[^]) They're false crashes. The program probably would've kept on going. :laugh: Leave my code alone, Windows! :rolleyes:
-
Richard MacCutchan wrote:
Reminds me of the good old days
I was thinking it reminded me of the little less old days (1992) when I was learning C/C++ pointers on a machine running DOS 5.x and Win 3.1 It was the same then. The machine or app didn't immediately crash or anything. Just kept going until that memory was used by something else. A lot of the crashing now is caused because of DEP (Data Execution Prevention[^]) They're false crashes. The program probably would've kept on going. :laugh: Leave my code alone, Windows! :rolleyes:
-
I first learned C under Dos 3.1 on an Olivetti PC. And the same problem of course, it just stopped when something went wrong.
Thats northing I learnt C on Amiga 500 with NorthC made CC on Linux look user friendly!
-
My last three major problems in my code involved buffer overruns. These are fun on the ESP32 or other platforms without memory protection because you don't crash when the Bad Thing(TM) happens. You crash in the aftermath as a consequence, by for example, trying to execute an illegal instruction because your data overwrote your code. Because of that, even *if* your stack dump isn't corrupt you still won't get much in the way of a hint as to where the actual error is. The bottom line is you get to debug it blind. I solved the last three times this happened, and it's making me a better troubleshooter. Damn it's difficult though.
To err is human. Fortune favors the monsters.
honey the codewitch wrote:
other platforms without memory protection
In current OSes (desktop) and with current C and/or C++ compilers it is not possible to corrupt memory by creating code incorrectly? Far as I know neither ANSI C nor ANSI C++ mandates how memory is managed. So it would be a value add if a C/C++ compiler added something in that fully protected memory. Seems like it would require specific language code usage by the programmer as well.
-
honey the codewitch wrote:
other platforms without memory protection
In current OSes (desktop) and with current C and/or C++ compilers it is not possible to corrupt memory by creating code incorrectly? Far as I know neither ANSI C nor ANSI C++ mandates how memory is managed. So it would be a value add if a C/C++ compiler added something in that fully protected memory. Seems like it would require specific language code usage by the programmer as well.
It is. I'm talking about memory protection which has nothing to do with C or C++. That's a facility of modern CPUs What will happen with memory protection is your program will crash at the point that you try to access non-executable memory, whereas without memory protection your program will attempt to execute it, probably succeeding for a few bytes, with inevitably terrible results. Edit: I explained that badly and misspoke. Let's say you have [ data ][ code ] laid out in memory ... then I'm writing to the data chunk, but I keep going after the ] end and start writing in the [ code ] area. Memory protection won't allow this. You will get an access violation once you try to write to [ code ]. Without it, you will simply overwrite part of your code and then the CPU will eventually try to execute it (most likely) at which point very bad things happen.
To err is human. Fortune favors the monsters.
-
I first learned C under Dos 3.1 on an Olivetti PC. And the same problem of course, it just stopped when something went wrong.
Olivetti! That brings back memories of my Olivetti laptop. 512K of memory, twin 720k floppy disks, no hard drive, CGA screen - good times! Programming in C. Compiler and source on one floppy, linker and libraries on the other.
- I would love to change the world, but they won’t give me the source code.
-
Olivetti! That brings back memories of my Olivetti laptop. 512K of memory, twin 720k floppy disks, no hard drive, CGA screen - good times! Programming in C. Compiler and source on one floppy, linker and libraries on the other.
- I would love to change the world, but they won’t give me the source code.
What a comfortable setup, you didn't have to swap disks.
-
My last three major problems in my code involved buffer overruns. These are fun on the ESP32 or other platforms without memory protection because you don't crash when the Bad Thing(TM) happens. You crash in the aftermath as a consequence, by for example, trying to execute an illegal instruction because your data overwrote your code. Because of that, even *if* your stack dump isn't corrupt you still won't get much in the way of a hint as to where the actual error is. The bottom line is you get to debug it blind. I solved the last three times this happened, and it's making me a better troubleshooter. Damn it's difficult though.
To err is human. Fortune favors the monsters.
Age old problem. The best one can do is lot of bounds checking in one's code. As my old college CS. prof used to say about people coming to him with programming issues: "You are off by 1 somewhere."
"A little time, a little trouble, your better day" Badfinger
-
Age old problem. The best one can do is lot of bounds checking in one's code. As my old college CS. prof used to say about people coming to him with programming issues: "You are off by 1 somewhere."
"A little time, a little trouble, your better day" Badfinger
It wasn't a fencepost error/off-by-one error. It was something far more destructive. I ended up writing out twice the memory I intended to.
To err is human. Fortune favors the monsters.
-
It wasn't a fencepost error/off-by-one error. It was something far more destructive. I ended up writing out twice the memory I intended to.
To err is human. Fortune favors the monsters.
Hey, if you're going overrun the buffer at least make it worth your while! Double your fun, that's what I always say!
-
Hey, if you're going overrun the buffer at least make it worth your while! Double your fun, that's what I always say!
Specifically
static void wav_voice_16_1_to_16_2(const voice_func_info_t& info, void*state) {
wav_info_t* wi = (wav_info_t*)state;
if(!wi->loop&&wi->pos>=wi->length) {
return;
}
uint16_t* dst = (uint16_t*)info.buffer;
for(int i = 0;ipos>=wi->length) {
if(!wi->loop) {
break;
}
wi->on_seek_stream(wi->start,wi->on_seek_stream_state);
wi->pos = 0;
}
if(player_read16s(wi->on_read_stream,wi->on_read_stream_state,&i16)) {
wi->pos+=2;
} else {
break;
}
uint16_t u16 = (uint16_t)((i16+32768U)*wi->amplitude);
for(int j=0;j
To err is human. Fortune favors the monsters. -
Richard MacCutchan wrote:
Reminds me of the good old days
I was thinking it reminded me of the little less old days (1992) when I was learning C/C++ pointers on a machine running DOS 5.x and Win 3.1 It was the same then. The machine or app didn't immediately crash or anything. Just kept going until that memory was used by something else. A lot of the crashing now is caused because of DEP (Data Execution Prevention[^]) They're false crashes. The program probably would've kept on going. :laugh: Leave my code alone, Windows! :rolleyes:
I started to pick up C++ with Borland's compiler in the DOS days but it didn't crystalize for me. I actually picked it up out of necessity while working in the field. That was a trial by fire, and not without its missteps, like forgetting to mark my destructors for my COM objects virtual. :~ But man, now that I have GCC and Clang, I feel so much freer than I do with MS compilers. It use to be that their compilers were subpar, which is why I went to GCC, but as they improved, I've gotten so used to GCC's (and largely Clang's) flavor of standards compliance that the MSVC one throws me. I can write code in MSVC++ until it starts getting template heavy. Then I'm always having to massage the syntax of the code I write to get it to fit MSVC's way of doing things. The issue is coding windows stuff with it. You actually have to patch the direct x headers because of a nuanced difference in how GCC returns certain types from functions.
To err is human. Fortune favors the monsters.
-
Specifically
static void wav_voice_16_1_to_16_2(const voice_func_info_t& info, void*state) {
wav_info_t* wi = (wav_info_t*)state;
if(!wi->loop&&wi->pos>=wi->length) {
return;
}
uint16_t* dst = (uint16_t*)info.buffer;
for(int i = 0;ipos>=wi->length) {
if(!wi->loop) {
break;
}
wi->on_seek_stream(wi->start,wi->on_seek_stream_state);
wi->pos = 0;
}
if(player_read16s(wi->on_read_stream,wi->on_read_stream_state,&i16)) {
wi->pos+=2;
} else {
break;
}
uint16_t u16 = (uint16_t)((i16+32768U)*wi->amplitude);
for(int j=0;j
To err is human. Fortune favors the monsters.This reminds me of some programming I did once upon a time in C++ Borland. Did not like it one bit. Literally. :laugh:
-
honey the codewitch wrote:
other platforms without memory protection
In current OSes (desktop) and with current C and/or C++ compilers it is not possible to corrupt memory by creating code incorrectly? Far as I know neither ANSI C nor ANSI C++ mandates how memory is managed. So it would be a value add if a C/C++ compiler added something in that fully protected memory. Seems like it would require specific language code usage by the programmer as well.
I totally misread you when a responded before. Coming back to read the lounge and realized you weren't saying what I thought you were saying. Sorry. Yes, that would be cool. But honestly, I don't run into the problem enough that I'd want the necessary runtime checks that would come with preventing it. Unless maybe it only did it on debug builds. I think there are tools like this out there, but I'd have to dig.
To err is human. Fortune favors the monsters.
-
It wasn't a fencepost error/off-by-one error. It was something far more destructive. I ended up writing out twice the memory I intended to.
To err is human. Fortune favors the monsters.
"Off by one" example is not meant to be necessarily be literal. It means that somewhere a boundary check is not occurring or is not detected, a memory operation is corrupted, lots of things that may lead to a single point failure. Buffer overflows were and maybe still are reasons many virus attacks because they wander into uncontrolled parts of memory. Recall the infamous P = malloc( 0 ); not returning a null pointer. I know your system is quite complex, hence your explorations into the complex interactions in world of hardware and software at the lower levels, so my feedback may be naive. Keep at it.
"A little time, a little trouble, your better day" Badfinger
-
"Off by one" example is not meant to be necessarily be literal. It means that somewhere a boundary check is not occurring or is not detected, a memory operation is corrupted, lots of things that may lead to a single point failure. Buffer overflows were and maybe still are reasons many virus attacks because they wander into uncontrolled parts of memory. Recall the infamous P = malloc( 0 ); not returning a null pointer. I know your system is quite complex, hence your explorations into the complex interactions in world of hardware and software at the lower levels, so my feedback may be naive. Keep at it.
"A little time, a little trouble, your better day" Badfinger
jmaida wrote:
Buffer overflows were and maybe still are reasons many virus attacks
Yeah, I often joke when this happens that I wind up attacking my own code with an exploit. :-D
To err is human. Fortune favors the monsters.
-
jmaida wrote:
Buffer overflows were and maybe still are reasons many virus attacks
Yeah, I often joke when this happens that I wind up attacking my own code with an exploit. :-D
To err is human. Fortune favors the monsters.
-
Age old problem. The best one can do is lot of bounds checking in one's code. As my old college CS. prof used to say about people coming to him with programming issues: "You are off by 1 somewhere."
"A little time, a little trouble, your better day" Badfinger
jmaida wrote:
The best one can do is lot of bounds checking in one's code.
In embedded you really have to make each line count. When you have a handful of microseconds to compute the nes state of the transistors that are piloting a motor, your clock is 40 Mhz if you're lucky and you have 3kB of RAM and 64kB of flash bounds checking in the code is really on a if-needed basis. You just check the memory window while debugging step by step and infer from that.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
My last three major problems in my code involved buffer overruns. These are fun on the ESP32 or other platforms without memory protection because you don't crash when the Bad Thing(TM) happens. You crash in the aftermath as a consequence, by for example, trying to execute an illegal instruction because your data overwrote your code. Because of that, even *if* your stack dump isn't corrupt you still won't get much in the way of a hint as to where the actual error is. The bottom line is you get to debug it blind. I solved the last three times this happened, and it's making me a better troubleshooter. Damn it's difficult though.
To err is human. Fortune favors the monsters.
buffer over/under write/read is probably the only bug i have never created as i have always been painstakingly careful about such . in fact at a job many years ago i wrote a quick little memory protection scheme . it quickly found the source of memory errors though the project failed miserably . as for your situation would it make sense to run your code on a desktop/laptop in a kind of simulator of your devices w/ memory protection code so as to find any such errors ? - Best
