Thread: Function Parameters Corrupt

  1. #1
    Registered User
    Join Date
    Jul 2008
    Posts
    8

    Function Parameters Corrupt

    Hi,

    I'm new to this forum and was hoping someone could help me debug a sanity-questioning problem I'm having. Consider the following function declaration and call...


    Code:
    int encode_buffer(large_struct_t * gfp, const int buffer[16][2][1152],
                           int nsamples[16], unsigned char mp3buf[16][16384], 
    		       int mp3buf_size[16],
                           int num_frames_to_encode, 
                           int mp3sizes[16]);
    
    void my_func() {
        int mp3sizes[16];
        int mp3buf_size[16];
        int Buffer[16][2][1152];
        int num_frames_to_encode;
        large_struct_t *gf;
        unsigned char mp3buffer[16][16384];
        int iread_arr[16];
    
        ...
    
         encode_buffer(gf, Buffer, iread_arr, mp3buffer, mp3buf_size, 
                                num_frames_to_encode, mp3sizes);
    
        ...
    }
    For some reason, I'm experiencing some corruption of the function parameters, once the function is executed. When I step through the execution, I can see that just before the function call, all the values being passed are sane values, but once I step inside the function, the values become muddled. With this specific configuration, I lose the first dimension of each array. The address of these values remains the same, but somehow their contents is altered in the function call. The scalar value (num_frames_to_encode) remains consistently correct.

    I have also tried alternative function prototypes along the following lines:

    Code:
    int encode_buffer(large_struct_t * gfp, const int buffer[16][2][1152],
                           int nsamples[16], unsigned char *mp3buf[16], 
    		       int mp3buf_size[16],
                           int num_frames_to_encode, 
                           int mp3sizes[16]);
    Where the type of mp3 buf is "unsigned char *mp3buf[16]." In my mind, either of these prototypes should be fine (multidimensional arrays are represented as an array of pointers to an array, right?). I should note that this is part of a very large program, and doing simpler sanity checks reveal to me that at least the first prototype should be correct, given only this function and a call to it.

    If anyone has any ideas or solutions, I would greatly appreciate hearing them! Thanks!
    Last edited by cecomp64; 07-10-2008 at 11:43 AM. Reason: fix typo

  2. #2
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    > large_struct_t *gf;
    Code:
    large_struct_t gf; // an actual instance.
    
         encode_buffer(&gf, Buffer, iread_arr, mp3buffer, mp3buf_size, 
                                num_frames_to_encode, mp3sizes);
    If the function does gfp->anything, then you need it to point somewhere.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  3. #3
    Registered User
    Join Date
    Jul 2008
    Posts
    8
    Ah sorry, this is a typo in my haste to copy only relevant parts of the code. Please assume that this points to a previously instantiated, valid value.

    Thanks.

  4. #4
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    > In my mind, either of these prototypes should be fine (multidimensional arrays are represented as an array of pointers to an array, right?).
    No.

    If you're trying to pass unsigned char mp3buffer[16][16384]; to a function, then the function prototype should be one of these
    Code:
    func ( unsigned char mp3buffer[16][16384] );
    func ( unsigned char mp3buffer[][16384] );
    func ( unsigned char (*mp3buffer)[16384] );
    That is, you have a pointer to an array.

    unsigned char *mp3buffer[16384] would be something completely different, and that is an array of pointers. Although it looks pretty similar to the last example, it is very different and the ( ) make all the difference.

    Short answer, if you're getting any warnings with this, then you're doing something wrong.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  5. #5
    Registered User
    Join Date
    Jul 2008
    Posts
    8
    Quote Originally Posted by Salem View Post

    unsigned char *mp3buffer[16384] would be something completely different, and that is an array of pointers.

    Short answer, if you're getting any warnings with this, then you're doing something wrong.
    Alright, that solves one mystery, but the basic problem still remains, even with a prototype of the form

    Code:
    func (unsigned char mp3buffer[16][16384]);
    No warnings are generated corresponding to this function. The oddity of all this seems to point to either a very minor mistake, or some kind of stack corruption. I should mention that I'm using Visual Studio's C compiler (not by choice) to compile my code.

    Again, a simplified sanity test-case has no problems passing and manipulating the parameters as I am doing in the larger application. Any ideas?

  6. #6
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    > int Buffer[16][2][1152];
    > unsigned char mp3buffer[16][16384];
    These two take up 400K of space on the stack.

    The default stack size is about 1MB for most machines. If this is at all recursive, or you have lots of other similarly sized variables around, it could be a problem.
    If it isn't recursive, consider
    static unsigned char mp3buffer[16][16384];

    Without a small-ish example which shows the problem, it's a lot of guess-work.

    Also bear in mind that if you're single-stepping at the assembler level, it takes several instructions to properly set up the stack frame, during which time everything will look weird.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  7. #7
    Registered User
    Join Date
    Jul 2008
    Posts
    8
    Thanks for all the replies. It turns out my problem was a combination of stack issues and misinterpreting my debugging results.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Compiling sample DarkGDK Program
    By Phyxashun in forum Game Programming
    Replies: 6
    Last Post: 01-27-2009, 03:07 AM
  2. function with variable number of parameters
    By mikahell in forum C++ Programming
    Replies: 3
    Last Post: 07-23-2006, 03:35 PM
  3. Change this program so it uses function??
    By stormfront in forum C Programming
    Replies: 8
    Last Post: 11-01-2005, 08:55 AM
  4. C++ compilation issues
    By Rupan in forum C++ Programming
    Replies: 1
    Last Post: 08-22-2005, 05:45 AM
  5. Replies: 5
    Last Post: 02-08-2003, 07:42 PM