I mean, we know exactly which way the stack grows on any given CPU architecture. The data corruption caused by the stack overflow is completely self inflicted. This, in turn, caused the engine to run, but with the throttle “stuck” in the wide-open position, because the “kitchen-sink” TaskX, as Michael calls it, which controlled the throttle among many other things, was dead.
![stack smashing detected recursion stack smashing detected recursion](https://3.bp.blogspot.com/-ZMMKeqPguaQ/U0qhg4g9TtI/AAAAAAAAAVU/yHk9ETfazgM/s1600/recursion_forbidden.png)
But due to the memory corruption some tasks got “killed” (or “forgotten”) by the OSEK real-time operating system while other tasks were still running. Instead, the problem was exactly that the system kept running after the stack overflow.
![stack smashing detected recursion stack smashing detected recursion](https://i.ytimg.com/vi/SW14tOda_kI/maxresdefault.jpg)
In fact, an immediate system failure followed by a reset would have saved lives, because Michael explains that even at 60 Mph, a complete CPU reset would have occurred within just 11 feet of vehicle’s travel. The crucial aspect in the failure scenario described by Michael is that the stack overflow did not cause an immediate system failure. Traditionally, however, such a stack is called "descending".)
#Stack smashing detected recursion code
The following two slides from Michael’s testimony explain the memory layout around the stack and why stack overflow was likely in the Toyota code (see the complete set of Michael’s slides).īarr's Slides explaining Toyota stack overflow (NOTE: the stack grows "up" in this picture, because "Top" represents a lower address in RAM than "Bottom". In his deposition, Michael explains how a stack overflow could corrupt the critical variables of the operating system (OSEK in this case), because they were located in memory adjacent to the top of the stack.
#Stack smashing detected recursion trial
The recent trial testimony delivered at the Oklahoma trial by an embedded guru Michael Barr for the fist time in history of these trials offers a glimpse into the Toyota throttle control software. Unless you’ve been living under a rock for a past couple of years, you must have heard of the Toyota unintended acceleration (UA) cases, where Camry and other Toyota vehicles accelerated unexpectedly and some of them managed to kill people and all of them scared the hell out of their drivers.
![stack smashing detected recursion stack smashing detected recursion](https://image.slidesharecdn.com/2371037c-1a05-4da0-b24f-5b31e9bea3f5-161205051318/95/marcus-taylor-resume-buzz-122016-2-638.jpg)
Stack Overflow Implicated in the Toyota Unintended Acceleration Lawsuit If you are less lucky, however, your program will limp along in some crippled state, not quite dead but not fully functional either. If you are lucky, your program will crash quickly. You can watch the YouTube video to see the details, but basically when the stack overflows, memory beyond the stack bound gets corrupted and your code will eventually fail. In the latest Lesson #10 of my Embedded C Programming with ARM Cortex-M Video Course I explain what stack overflow is and I show what can transpire deep inside an embedded microcontroller when the stack pointer register (SP) goes out of bounds.