3 Replies Latest reply on Aug 12, 2011 4:45 PM by Steve.Clamage-Oracle

    Can arguments be corrupted on passing in to function?


      I'm seeing something that's got me stumped. Maybe you folks can advise.

      What appears to be a valid arguments are getting corrupted when passed to a different function.

      Here is my set up:

      - LibA.a
      - LibB.a
      - SampleApp
      - MyApp

      The bad function call is going from LibA in to LibB.

      LibA, LibB and SampleApp have all been pre-complied (thankfully in debug mode) by an older version of Sun Studio on Solaris x86/64. SampleApp uses both LibA and LibB and runs just fine on my system.

      MyApp uses both LibA and LibB in a manner similar to SampleApp. Yet, MyApp crashes due to this pointer corruption.

      When single stepping the code, I see the pointer in the caller being valid and being passed as a parameter. In the callee, the value of the passed-in parameter pointer in simply wrong.

      Note: The caller is in the pre-compiled LibA.a and the callee is in the pre-compiled LibB.a I'm never even touching that code to recompile it. Further, the code itself must be correct since SampleApp uses those functions, and runs fine.

      Thus, I'm thinking that my error is in the linking stage, but I'm not sure what it could be.

      Any ideas?

      Thank you,

      Edited by: 878694 on Aug 11, 2011 3:52 PM
        • 1. Re: Can a pointer be corrupted on passing in to function?
          Let's see if I understand: A pointer to a char array is passed to a function, and the value of the pointer as received is different from the address of the array.

          The problem must be that myString, or a pointer to myString was declared differently in the two places. Example:
          char* aaa   = "aaa";
          char  bbb[] = "bbb";
          extern void foo(char*);
          void f()
              foo(aaa); // pass the contents of the pointer at aaa
              foo(bbb); // pass the address of bbb
          Although this code is not quite like yours, look for a declaration in libA that does not match the way myString is being used.
          • 2. Re: Can a pointer be corrupted on passing in to function?
            Hi Steve,

            Upon closer evaluation, it seems that all the args to the called function are being corrupted. I was fooled by a "correct looking", but actually wrong, value in the other param.

            (I've updated my post.)

            While this is is now a very different question, I still don't know where to start looking. The pre-complied code works fine in SampleApp, and there does not seem to be any issue calling in to LibA/LibB from my code. Just in that LibA-to-LibB call. (I don't yet know if other LibA-LibB calls work.... looking for one.)

            Very odd.

            • 3. Re: Can a pointer be corrupted on passing in to function?
              It's impossible to say what is wrong without a fairly complete example, preferably one that could be compiled and run to see the problem. Some generic guesses:

              1. Compiler bug. The code should be recompiled with a new compiler where the bug has been fixed. Impossible to say what sort of bug that might be without a test case.

              2. As in my original comment, the two libraries see inconsistent declarations. For example, after one library was built, a declaration in a common header was changed and the other library, or some binary in it, was built using the different declaration. This kind of error is common when makefiles do not express all the needed dependencies. The fix is to delete all binaries and recompile everything (to be sure no change is missed).

              2a. A related error is when common declarations are repeated in .cc files instead of being placed only in header files and included where needed. What are supposed to be identical declarations get out of sync. The fix is to reorganize the source code to eliminate copies of declarations, delete all binaries and recompile everything (to be sure no change is missed).

              3. You are not seeing what you think you are seeing. For example, if the address of a derived class is passed to a pointer-to-base-class, the address might need to be adjusted. In this case, the difference in values is correct, and something else is causing whatever incorrect program behavior you see.