1

Morning,

I have just finished pset4 recover. The program works correctly and I can see all 16 jpgs and they are labeled correctly however check50 is failing:-

jharvard@appliance (~/Dropbox/CS50/pset4/jpg): check50 2014.fall.pset4.recover recover.c
:) recover.c exists
:) recover.c compiles
:( recovers 000.jpg correctly
:( recovers 001.jpg through 014.jpg correctly
:( recovers 015.jpg correctly
https://sandbox.cs50.net/checks/c0861d692c4a462d912b2816c13532c7

I have run Valgrind and have no leaks and just one error that I can't get to the bottom of (but i don't think this is why check50 is failing):

==4618== 1 errors in context 1 of 1:
==4618== Syscall param write(buf) points to uninitialised byte(s)
==4618==    at 0x4166C73: __write_nocancel (syscall-template.S:81)
==4618==    by 0x40FABA0: _IO_file_write@@GLIBC_2.1 (fileops.c:1261)
==4618==    by 0x40F9DDE: new_do_write (fileops.c:538)
==4618==    by 0x40FBB4D: _IO_do_write@@GLIBC_2.1 (fileops.c:511)
==4618==    by 0x40FB41F: _IO_file_close_it@@GLIBC_2.1 (fileops.c:165)
==4618==    by 0x40EF4FF: fclose@@GLIBC_2.1 (iofclose.c:59)
==4618==    by 0x8048A57: main (recover.c:110)
==4618==  Address 0x4038600 is not stack'd, malloc'd or (recently) free'd
==4618== 
==4618== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Any help would be greatly appreciated.

Thx

5
  • Can you clarify something? You said that you can see all 16 jpegs. Does that mean that you see that the files exist, or have you actually looked at the images created? Next, have you checked the file sizes of those 16 files? If they are all the same file size, something is wrong. – Cliff B Jul 27 '15 at 7:46
  • Check this more detailed answer by @CliffB. cs50.stackexchange.com/a/10793/7539 – ChrisG Jul 27 '15 at 7:48
  • Thanks, Chris. That answer is good info, but less applicable here. The bmp side of the pset manipulates a lot of data in the files, where this one should be nothing more than just copying blocks of data until the next signature is found. If the blocks aren't copied, then the images will probably be corrupted here, or the signature won't be in the first 4 bytes of a file and no image will be shown because the files aren't recognized as jpegs. More commonly, files will all be the same size, and typically either 0 bytes or 512 bytes when things go wrong. So, I'm waiting to see file sizes, etc. – Cliff B Jul 27 '15 at 7:59
  • I can open and see all jpegs, here are the file sizes:- – Gordon Jul 27 '15 at 8:02
  • I can open and see all jpegs, here are the file sizes:- 000.jpg 152.1kB, 001.jpg 389.6kB, 002.jpg 197.1kB, 003.jpg 70.1kB, 004.jpg 164.4 kB, 005.jpg 107kB, 006.jpg 90.6kB, 007.jpg 119.3kB, 008.jpg 168.4kB, 009.jpg 320kB, 010.jpg 82.4kB, 011.jpg 217.6kB, 012.jpg 307.7kB, 013.jpg 160.3kB, 014.jpg 143.9kB, 015.jpg 383kB – Gordon Jul 27 '15 at 8:13
2

The two most common reasons for check50 to fail with a TODO message (as yours has):

You are not closing each jpg file before opening the next one.

or

You are writing extra bytes to each jpg. These are the exact sizes you should have:

-rw------- 1 jharvard students   151552 Jul 20 12:18 000.jpg
-rw------- 1 jharvard students   389120 Jul 20 12:18 001.jpg
-rw------- 1 jharvard students   196608 Jul 20 12:18 002.jpg
-rw------- 1 jharvard students    69632 Jul 20 12:18 003.jpg
-rw------- 1 jharvard students   163840 Jul 20 12:18 004.jpg
-rw------- 1 jharvard students   106496 Jul 20 12:18 005.jpg
-rw------- 1 jharvard students    90112 Jul 20 12:18 006.jpg
-rw------- 1 jharvard students   118784 Jul 20 12:18 007.jpg
-rw------- 1 jharvard students   167936 Jul 20 12:18 008.jpg
-rw------- 1 jharvard students   319488 Jul 20 12:18 009.jpg
-rw------- 1 jharvard students    81920 Jul 20 12:18 010.jpg
-rw------- 1 jharvard students   217088 Jul 20 12:18 011.jpg
-rw------- 1 jharvard students   307200 Jul 20 12:18 012.jpg
-rw------- 1 jharvard students   159744 Jul 20 12:18 013.jpg
-rw------- 1 jharvard students   143360 Jul 20 12:18 014.jpg
-rw------- 1 jharvard students   382464 Jul 20 12:18 015.jpg

It looks from your comment that all of your JPGs are slightly larger, perhaps an extra 512 bytes? I would check your writing loop to make sure it isn't running one extra time per jpg.

1
  • OK Ive changed my code now and it is recovering the first jpg ok with the correct size and then it recovers another 15 unreadable jpgs and I can't figure out why, I've been looking at the code for the last hour and am just baffled ? – Gordon Jul 27 '15 at 12:19

You must log in to answer this question.

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