Is it possible to localize violation of structures in memory?

Question

Microcontrollers

There is a large project in which a bug has appeared, the source of which is not obvious. I ask for the help of experts.
The essence of the problem: when executing the code, a Floating Point Error (Domain or Overflow) system exception occurs in a place where there are no floating point operations - we get a string, exit the function with a string return and catch the exception without entering the parent function.
There is a suspicion that the code contains incorrect code that, when written to memory, climbs onto neighboring structures and spoils them. Is it possible to localize the location of the violation?
Some additional information on the issue. The error is guaranteed to appear when using the message output function (a logical function, without working with hardware), but it appears in a completely different place. First, the task manager object is called, which in an endless loop calls other task objects. And it crashes on a specific task, which used to work without failures before (and before the start of the message output and in previous versions of the program). and there should be no floating point exceptions for this task object.
The program is written in C++ to work in DOS and must eventually be executed on a PLC based on a 16-bit Intel 80188 processor. This is where the error appears. To debug the application, the source code compiled under the PC is used, on which this problem has not yet been caught as an exception, but if there is an incorrectness in the source code, then it should also appear on the PC (memory leaks?).
I ask for advice, how to identify the problem? Use profilers, static code analyzers? So far I haven't had to work with them. Can they help in finding the place of violation of memory structures?

Answer 1

The very first thing is to run the program through valgrind (you can do it on a regular machine). Look for "Invalid read of size..." or Invalid write - these will be memory errors. Well, there might be leaks.
The second is to look carefully at the code where there is a division (operators / and %) and check if division by zero is possible there - FPE may turn out to be a banal consequence of division by zero.

Answer 2

In such cases, I usually use the programmer's method of catching a lion in the desert.
I remove the code in parts and check if there is an error. Thus, a faulty area is identified.