Where hardcoded values are stored ?

Question

Hi

For an investigation i need to know where hard-coded values are stored.

Question : A function having hard-coded values inside it , and this function is called by many threads at same time , is there any chance that that hard-coded value will be corrupted.

For example : myFunc is called by many thread at same time . can literal "Unhandled exception:" be corrupted

  void myFunc()
   {
      EXCEPTION_RECORD ExceptRec
      bool  retValue=doSomething(ExceptRec);
      if(!retValue)
      {
          log ("Unhandled exception:"<< " code = " << hex << ExceptRec.ExceptionCode
   << " flags = " << ExceptRec.ExceptionFlags
   << " address = " << ExceptRec.ExceptionAddress)

         // log is macro which will insert content into ostrstream
      }
   }

Function doSomething looks like :

bool doSomething(EXCEPTION_RECORD &ExceptRec)
  {
    __try
    {
       // some code here

    }
    __except (ExceptRec = *(GetExceptionInformation())->ExceptionRecord,  
        EXCEPTION_EXECUTE_HANDLER)
    {  
     return false;
    }

    return true;
  }

Answer 1

No, the string literals will not be corrupted in that situation because they're not being written to.

However: if you don't lock/synchronize the use of that output stream, you may see intermixing of output that resembles corruption.

Answer 2

String literals are normally stored in a read-only section of the process memory and in your code, you are not (and you shouldn't) write to them. They are being used to construct a new string with the contents of those literals copied into it.

If you were writing to the memory addresses of those literals, you'd know it :) (i.e. it would normally crash the program)

Answer 3

Literal strings are stored in the .data section of your program image when they are compiled. The .data section is usually mapped into read only memory so it cannot be corrupted just like the .code section. You can view the .data section of a windows exe/dll by using dumpbin.exe that comes with visual studio.

There is no easy way to corrupt this literal, it can be done if you modify the permisions of the memory page it is stored in, but you would have to explicitly do that by using an OS api, not a c++ api. The address hard coded into the machine code at compile time is a relative offset (if memory serves me it is to the data section base). This offset is added to the base address supplied by the operating system loader.

If your stack is corrupt you can end up with situation where the base address is invalid so when the offset is added, the literal looks corrupt.