Home/ Questions/Q 898667
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T15:05:04+00:00

In one RTOS, i’m debugging one issue which is, program is crashing one point

  • 0

In one RTOS, i’m debugging one issue which is, program is crashing one point always when it send a 8-bit value (Lets call it ‘Int8 rogue_int’)to a function (lets call it ‘Infected( Int16 )’ ) whose definition is taking that variable as 16-bit variable. Before entering to that last function Infected(..), value for ‘rogue_int’ is proper but as soon as it enters to Infected(..) fn it is having some junk value and it hits a assert. normally my thinking is casting 8-bit to 16-bit variable should not result any issue but there could not be any other problem i can not find in between that could corrupt the static memory.

i have given it much thought and i came up some theory that since this is hitting assert after some time (lets say 2-3 hrs of execution) so initially static memory is nice and clean and not much grown towards heap but as it grows then during casting 8 bit to 16 bit, it takes 8 bits from real no (which is rogue_int here) but it takes additional 8-bits of memory chunk that was just assigned to this variable to make it 16-bit. this newly added 8-bit could be corrupted and that could make complete no as invalid.

My question here is that, does my 2nd para above make any sense to C++ experts?? Does casting 8 to 16 is always safe (I was thinking it is always safe that is why i’m not submitted my thoughts to higher up)?? if you think i’m wrong then please suggest alternative that could lead to this prob. (assert always seen hit ONLY at one point in function ‘Infected(..)’… not any any other place)

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I’m not a C++ expert, but what you’ve described does not make any sense. Casting from an 8-bit type to a 16-bit type cannot result in uninitialized memory being incorporated into to the value–upcasts of this type have narrow, strictly-specified semantics, and the compiler can’t just grab an extra adjacent byte and add it to your value.

    What you’re describing sounds like a buffer overflow from some other part of the program. I suggest using a validation tool like valgrind (Linux) or AppVerifier (Windows) to check your memory accesses and find the buffer overflow at its source.

    • 0