I have a number of issue but the most disatarous is my malloc ./resize': corrupted size vs. prev_size: 0x0000000001903480 *** when calling the function currently. The problem there (besides sucking at malloc) is not knowing what to use in place of arrayIndex to make malloc expand with the array size.

I've inserted a 1000 in place of arrayIndex only to get it to run and make it further. Not a valid solution at all.

The next issue is with the k loop. I am trying to push all the indexes into the malloced array, and keep track with the outside variable arrayindex. When I log that number out, it works out, but if it doesn't crash the outputted image is a solid color, and does not match the original. I know I have padding issues! But then the image should work okay when there is no padding, right? LIke when n=4, or 12 bytes, in the debugger padding is 0, even in this case the image output is wrong.

My point is, I'm aware I have padding issues but perhaps and the two problems above are more immovable. Padding can be fixed third.

int arrayIndex = 0;
    // put pixels in an array

    RGBTRIPLE* arr = malloc(arrayIndex * sizeof(RGBTRIPLE));
    RGBTRIPLE* arr = malloc(bi.biWidth * sizeof(RGBTRIPLE));

    // iterate over infile's scanlines
    for (int i = 0, biHeight = abs(bi.biHeight); i < biHeight; i++)
        // iterate over pixels in scanline
        for (int j = 0; j < bi.biWidth; j++)
            // temporary storage
            RGBTRIPLE triple;

            // read RGB triple from infile
            fread(&triple, sizeof(RGBTRIPLE), 1, inptr);

            // write each triple into array above

            for(int k = 0;k < n;k++){
                    arr[arrayIndex] = triple;
                    printf("%i", arrayIndex);


        // iterate n times, once equals a row
        for(int row = 0;row < n; row++){

            for(int item = 0;item < bi.biWidth;item++){

                fwrite(&arr[item], sizeof(RGBTRIPLE), 1, outptr);


            if(newPadding > 0){
                    for (int padCount = 0; padCount < newPadding; padCount++)

                    fputc(0x00, outptr);
        fseek(inptr, padding, SEEK_CUR);

I'm totally stuck and despite tons of research I cannot get past this. Not too sure where do go at this point.


After the first row of pixels is processed, where is ArrayIndex reset to 0?

Without the reset, it will just continue to increment, accessing memory well beyond the end of the arr array.

On a related note, it looks like the array should be sized to equal biWidth of the output file. Can't tell if it is or not because that code isn't posted.

If this answers your question, please click on the check mark to accept. Let's keep up on forum maintenance. ;-)

  • At first I thought, of course! But it did not work. After the closing of the j loop I added arrayIndex = 0 to try and reset the loop. But n=2 still overflows the memory. I have also since set the malloc to RGBTRIPLE* arr = malloc(bi2.biWidth* sizeof(RGBTRIPLE)); This has also made no difference. What is the "proper" way to allocate memory here? This can't be it.
    – Mote Zart
    Mar 22 '18 at 2:00
  • No, it isn't quite right. It is allocating the right amount of memory to a pointer, not an array of rgbtriples. I'll let you think about what's missing and what's wrong first. Think about what defines the number of triples needed. And, if you're adding padding to the array (which is not composed of rgbtriples), what data type do you need? If you can't figure it out, leave a comment. ;-)
    – Cliff B
    Mar 22 '18 at 2:07
  • I don't know to printf rgbtriples. This has made it hard to visualize. They are super abstract. I don't even know what kind of data they are. So I guess if you could just tell me it might help. Although I've run through the code line by line. It seems to take the row, put it into an array, and then write it back out to the outfile. The padding might be off, but I tried to write in the new padding at the end of the row, skip over the infile padding before starting the next. Do I need to start over? I get back a bmp wrong clr gist.github.com/chrisdel101/510c6233df91f01fc8191cffb4cd1dd7
    – Mote Zart
    Mar 22 '18 at 2:50
  • An RBGTRIPLE is a 3 byte long piece of data that sets the color of a pixel. The padding is correct. You've still missed a critical point. As coded, arr contains pointers, not data. A pointer is an 8 bit address, not an RGBTRIPLE. You should consider creating an array of RGBTRIPLEs. It should have enough elements for the number of pixels in a line of pixels in the output file. Further, create it on the stack, not in heap memory using a malloc. This won't fix everything, but it will get you going. If you have more questions, please open a new question.
    – Cliff B
    Mar 22 '18 at 3:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .