Access violation when reading [00000000]?

[phal]

Hi,

It's a code for copying a file. It had been working fine but now something goes wrong and it causes the main process to crash, even without an error message.

I can't figure out what's wrong here, so I am adding the code here.

#include <windows.h>
#include <stdio.h>
#include <commctrl.h>
#include <stdlib.h>
#include <time.h>

CopyAFile(char * src, char * trg){
char c = 0;

FILE *fp = fopen(src, "rb");
FILE *fp1 = fopen(trg, "wb");

if(!(fp && fp1)){
MessageBox(0, "fopen()", 0, 0);
return 0;
}

fseek(fp, 0, SEEK_SET);

      while(!feof(fp)){
      fscanf(fp, "&#37;c", &c);
      fprintf(fp1, "%c", c);  //It crashes here, the first time fprintf() called
      }

fclose(fp);
fclose(fp1);

return 1;

}

Here is where it crashes, ntdll.dll. From OllyDbg.

7C901E24   > FF75 10        PUSH DWORD PTR SS:[EBP+10]
7C901E27   . 57             PUSH EDI
7C901E28   . 56             PUSH ESI
7C901E29   . E8 26FDFFFF    CALL ntdll.7C901B54
7C901E2E   .^EB AE          JMP SHORT ntdll.7C901DDE
7C901E30   > 0FB706         MOVZX EAX,WORD PTR DS:[ESI]
7C901E33   . 8B4D 10        MOV ECX,DWORD PTR SS:[EBP+10]
7C901E36   . 0301           ADD EAX,DWORD PTR DS:[ECX]
7C901E38   . 3D 00FE0000    CMP EAX,0FE00
7C901E3D   .^0F87 EEEDFFFF  JA ntdll.7C900C31
7C901E43   . 807D 14 00     CMP BYTE PTR SS:[EBP+14],0
7C901E47   . 0F85 977A0300  JNZ ntdll.7C9398E4
7C901E4D   > 8B4E 0C        MOV ECX,DWORD PTR DS:[ESI+C]
7C901E50   . 8D46 08        LEA EAX,DWORD PTR DS:[ESI+8]
7C901E53   . 8B10           MOV EDX,DWORD PTR DS:[EAX]
7C901E55   . 894D 08        MOV DWORD PTR SS:[EBP+8],ECX
7C901E58   . 8B09           MOV ECX,DWORD PTR DS:[ECX]     ;; DS:[00000000]=???
;;Access violation reading 00000000
7C901E5A   . 3B4A 04        CMP ECX,DWORD PTR DS:[EDX+4]
7C901E5D   . 8955 0C        MOV DWORD PTR SS:[EBP+C],EDX

It would be greatly appreciated if you can point out my mistake.

Thanks...

[Salem]

Use your debugger to put a breakpoint on the fprintf call, and examine all the parameters to make sure they're correct.

FWIW, I see two mistakes - the use of feof() is wrong (see the FAQ), and you use an & in the fprintf (which would just garbage the output).

[phal]

I corrected that & after I posted the message, I know it shouldn't be there. BTW, what's wrong with feof()?

PS. I don't wan't to use CopyFile() here, so please don't suggest it.

[laserlight]

BTW, what's wrong with feof()?

Nothing, just that your use of it is incorrect. Read the FAQ on Why it's bad to use feof() to control a loop.

[phal]

Ok, I corrected it, thanks.

The main problem is not related to this, anyway. Just before the fprintf() called, I can see that the file pointer, the char 'c' and the format string are all correct. I don't really see what is causing a crash like this.

[Salem]

Is that the whole program (except for a simple main to call it with 2 parameters)?

Or is it part of a much larger program?

One cause would be for example mis-using allocated memory in some way. Since fprintf may be calling malloc to allocate some space for the string it's about to create, then it would fail if you'd corrupted the heap.

Does your debugger show you a stack trace?

Link with the debug libraries if you have them for better information in debugging.

[phal]

Fixed it. I was using malloc() to initialize a few strings, in some other parts of the program. Like this:

char * string = (char *) malloc(1024);

Apparently this was poisoning the stack. I don't know how, I always had problems with malloc. So I changed them into something like this.

char string[1024];

The problem is fixed now. Thanks for the answers.

[matsp]

That does seem quite strange. I expect that something else is going wrong, and changing the layout of the stack simply makes the problem appear somewhere that it's not so obvious. Take it back to using malloc and debug the problem where it appears. If you don't, it will come back and haunt you some other time when you change something else and puts some vulnerable data in the place where it gets overwritten.

--
Mats

[VirtualAce]

For future reference, anytime you get a 0x00000000 access violation error in Windows it is basically saying you have a null pointer somewhere. Good place to start looking is inside object init code and memory allocation code.

[phal]

I will post if I find anything. Thanks.

[lruc]

I've never done anything lower than C++ so what exactly is that second set of code that you posted? I was also kind've curious about .o files. I opened it in notepad once and was really strange. What is this?

[tabstop]

I've never done anything lower than C++ so what exactly is that second set of code that you posted? I was also kind've curious about .o files. I opened it in notepad once and was really strange. What is this?

The second set of code was assembly language.

.o files are binary-format not-quite-executables, so strange is probably an understatement.

[lruc]

Thank you so much. You have no idea how many questions you just answered for me.