0

I have two main problems with recover:

  • Does not recover 049.jpg - Is this because my program is getting a freak EOF?
  • check50 hates me - Although my program recovers 000.jpg through 048.jpg fine, check50 decides to take its personal problems of sad faces out on me.

Here is a link to the check50 sandbox.

Apparently recover.c compiles... and recover.c doesn't compile.
Could anybody please help with this?

pset5 problem statement

Edit:
049.jpg does not exist at all. My program closes the outfile at the end of program provided outfile != NULL. It looks like 049.jpg ends up NULL, but I don't understand why.
Also, my loop condition is: while (1) {fread(...); if (feof(infile)) break; ...};.
Further, I have run Valgrind to check for memory leaks:

TheBrainyOne (~/Dropbox/pset5/jpg) $ valgrind --leak-check=full --show-reachable=yes ./recover
==7693== Memcheck, a memory error detector
==7693== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==7693== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==7693== Command: ./recover
==7693== 
==7693== 
==7693== HEAP SUMMARY:
==7693==     in use at exit: 0 bytes in 0 blocks
==7693==   total heap usage: 2 allocs, 2 frees, 704 bytes allocated
==7693== 
==7693== All heap blocks were freed -- no leaks are possible
==7693== 
==7693== For counts of detected and suppressed errors, rerun with: -v
==7693== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

The allocs and frees are fopen() and fclose(), respectively.
The --show-reachable=yes just means 'show the locations of memory blocks that have pointers to them and are therefore recoverable rather than simply telling me, the user, how much of it was lost.'
Note that no leaks are possible.

Edit: FINAL DAY, HELP WOULD BE APPRECIATED

To discuss, go to the chat: Discussion between wallek876 and TheBrainyOne

TheBrainyOne out.

Improve this question
7
  • The problem with the last jpg is probably because your loop is running one more time than the needed due to the time you check for the EOF inside the loop, but it is hard to tell for sure without more information. And probably when you fix this, the other issue should also be corrected. – wallek876 Dec 30 '14 at 18:02
  • @wallek876 049.jpg does not exist at all. My program closes the outfile at the end of program provided outfile != NULL. It looks like 049.jpg ends up NULL, but I don't understand why. (I have added this to the question.) – ChiCubed Dec 31 '14 at 4:02
  • Ok, something seems wrong. The condition to check for the EOF seems fine, but i think valgrind should show at least 51 allocs and 51 frees, 1 for the card image and 50 more, one for every jpg. I think the statments you are using to determine when to open or close a jpg may be wrong, i also think your program may not recover even the first jpg, but can't be more specific without more info. – wallek876 Dec 31 '14 at 6:50
  • Maybe if you try to write down the flow of your code with some pseudocode or diagram you'll see what may be wrong. – wallek876 Dec 31 '14 at 6:55
  • @wallek876 All images appear intact except for 049.jpg, which does not exist. The first jpg did not open at first, but that's because I used to close it before I wrote to it. I fixed that issue and it's just the last jpg now. – ChiCubed Dec 31 '14 at 7:40

You must log in to answer this question.

Browse other questions tagged .