C / C++ / MFC

Jack Puppy12-Apr-05 13:06

Jack Puppy

12-Apr-05 13:06

Does this describe your problem?

PRB: Synchronization Failure When Debugging

Pssst. You see that little light on your monitor? That's actually a government installed spy camera. Smile and wave to big brother!

theFrenchHornet13-Apr-05 5:01

theFrenchHornet

13-Apr-05 5:01

Thank you for finding that.

Somewhat, but the same thing happens when running a release version outside of Debug.

I am looking into the possibility that it is a bus problem caused by one of the cards in the system.

theFrenchHornet14-Apr-05 6:35

theFrenchHornet

14-Apr-05 6:35

Jack,

Turned out to be bad hotlink receiver card. Thanks again for your help.

Blake Miller14-Apr-05 9:29

Blake Miller

14-Apr-05 9:29

Now that was SERIOUSY cool to know. Thanks a ton Cool | :cool:

Blake Miller13-Apr-05 6:52

Blake Miller

13-Apr-05 6:52

What happens in your main program AFTER the while loop?

Since you only check for WAIT_OBJECT_0, if the hAcquireActive is not signaled within 100ms then your wait will return with WAIT_TIMEOUT and oyu will not enter your while loop.

Could this be your problem?

theFrenchHornet14-Apr-05 6:33

theFrenchHornet

14-Apr-05 6:33

Blake,

Good thinking, based on the amount of code I posted. I probably should have put more of the preceding code. The way the 2 interact, the Sub code - which is the one that was hanging on the sleep - has just set the event and checked that it is indeed set. Then comes the code I posted which is waiting for it to be reset by Main. If it has been reset, then there is no need to go into the loop.

During the debugging process, I took main out of the picture - created the event in Sub - and added some other lines inside the loop to guarantee things were for sure freezing on the Sleep or WaitForSingleObject, and they were.

The problem turned out to be a bad hotlink receiver card. It was replaced and now the problem is gone. The specifics of why it manifested that way I don't know. Since it works now, move on ...

In hindsight, since it was freezing to the extent the system had to be powered down, I might have more quickly ruled out that it was a coding problem.

Thanks for your help.

Reading A File

LighthouseJ12-Apr-05 11:33

12-Apr-05 11:33

I don't see how this got to be a problem, but I'm trying to read a bitmap file data in a raw fashion, byte by byte. I'm dealing with 8-bit images and therefore my data starts at 0x436 (1078 bytes from the beginning of the file). I'm trying to read the file in 64-byte chunks using file pointers. I've used fseek to position the data read pointer at the start of the data properly and it starts to read fine. When it gets to byte 62, that's when the problems begin. I have a variable that's set by ftell to tell me the file position which I interpret it to be the byte offset from the start of the file. Before the problem, the characters are fine and the file position is where it should be. Once it hits byte 62, the characters it gets are different from what it should be and the file position reads 5175 instead of 1141 for byte 63.

Here's 96 bytes of what I'm trying to read from:

1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E
1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1D 1D 1C 1C 1B 1D 1C 1B 1B 1A 1D
1D 1B 1B 1B 1B 1B 1C 1D 1B 1C 1C 1D 1D 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E

Here's the result, I've bolded the bytes that are different:

1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E
1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1D 1D 1C 1C 1B 1D 1C 1B 1B 1E 1E
1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E

The 1E's at the end of the snip are probably 1E's from somewhere else, the picture I'm reading is of a very white moon on a very black background. Any help would be greatly appreciated because this is an annoying problem.

edit: I was using fgetc to get a char (cast into a BYTE), but I tried using fscanf but the behavior is still the same, quite strange.

Follow-Up

LighthouseJ12-Apr-05 16:03

12-Apr-05 16:03

I traced through the read and here's what I found...

In the file pointer structure, there is a _ptr and a _cnt variable. When I open a file, the system seems to read in a chunk into memory and position _ptr at the front of it. As I read, the _ptr advances through the memory, and _cnt counts down to stop the read at the end of the chunk. When _cnt reaches zero, that may be a signal to the system to grab more data. Upon the signal, a new chunk of data overwrites the old data in the same memory area to save space, _cnt is reset to the amount of data it read in and _ptr points back to the beginning.

That sounds reasonable to me, however the data it reads in is very incorrect after the first block. I have the same file open in a hex editor and it's fine so the data is not corrupt. In the meantime, I may (relucantly) try a different method of reading a file, like iostream instead of file pointers but this is just disappointing to me. If anyone can say "it's because of X. Add "this statement;" and it'll work like a champ, I'll buy you a pint.

John R. Shaw12-Apr-05 19:16

John R. Shaw

12-Apr-05 19:16

All I've seen from this post and the original, is that you are making it too complicated.

What you are describing, of course, makes since for buffered file I/O. Since reading a sector at a time is more effiecient than reading a character at a time.

You can read all the file data into a single buffer, to simplify manipulation.

Note: If you read an entire .bmp into a buffer, eccentualy, you end up with a DIB.

INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen

LighthouseJ12-Apr-05 19:30

12-Apr-05 19:30

How is it too complicated? I want to position the file pointer at a location (0x436, 1078 bytes from the beginning of the file) and then read the rest of the file, sound like quite the ordinary task (with some argument attributed to file positioning). I can't perform this task because the data it pushes onto me isn't the data I have in the file. Am I wrong in the fact that the file pointer is not working correctly? Shouldn't it keep reading the file, not skip around some and then read past the end of the file and return FF's? I don't want to read the entire bitmap file, only the data portion.

John R. Shaw12-Apr-05 20:43

John R. Shaw

12-Apr-05 20:43

LighthouseJ wrote:
How is it too complicated?

You've were talking about reading a structured file one byte at a time. Which impilies you need to decipher those bytes (complicated, may be need for cross platfom).

Now:

You've been talking about reading a bitmap file and you are assuming that there will be data at 1078 to be read. If the file is realy an .bmp file, then you need to read the file header to determine where the bitmap data is and (for safey) what format the data is stored in.

LighthouseJ wrote:
Am I wrong in the fact that the file pointer is not working correctly?

I would bet good money that the answer is YES!

LighthouseJ wrote:
I don't want to read the entire bitmap file, only the data portion.

The entire file is the data portion!

BUT: I assmue by 'data portion' you mean the bitmap data bytes:

1) Open file.
2) Read BITMAPFILEHEADER (header).
3) Check that it is a .bmp file type. (header.bfType == 0x4D42)
4) Seek start of header (probably beginning of file).
5) Seek offset header.bfOffBits. (data offset from beginning of header)
6) Read data.

The above will work, but the moment the bitmap type is changed, yout code will fall apart.

INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen

LighthouseJ13-Apr-05 4:02

13-Apr-05 4:02

John R. Shaw wrote:
You've were talking about reading a structured file one byte at a time. Which impilies you need to decipher those bytes (complicated, may be need for cross platfom).

It's not that bad. For instance if I need to get the bitmap type, the "BM", I read in a character into a short, then shift the bits left 8-bits, then logically or that variable with the next character. When I read in an integer (4-bytes), I call the previous statement twice, and shifting by 16 bits in between the two calls. I do read in both headers and jump to that location (0x436) but every single 8-bit bitmap file always begins data at that same address so in the interest of simplifying the explanation, I just said I would always go to that byte offset.

John R. Shaw wrote:
... the moment the bitmap type is changed, yout code will fall apart.

I have conditionals in the right places to make sure the file that's read is of the right type, bit depth, size, etc....

Of course, all of this you've brought up is a non-issue because I have no problems reading the bitmap headers, only when I get to that particular location.

I looked at another reply from rateep and he pointed out the problem with a very concise on-topic response to my problem and it fixed my problems.

Ryan Binns12-Apr-05 18:25

Ryan Binns

12-Apr-05 18:25

Show us your code and we might be able to help...

Ryan

"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"

LighthouseJ12-Apr-05 19:16

12-Apr-05 19:16

Well, it's kind of spread out, but I can put the relevant parts back together. I have a class that doles out the data to the function I'm trying to use it in. It's pretty standard file pointer things and I've used file pointers exclusively in the past on countless programs.

Here's some code snips:

CBitmapFile::CBitmapFile(CString fileName) {<br />
bmpFP = fopen((LPCTSTR)fileName, "r");

Where bmpFP is a member variable in CBitmapFile.

Here's the function that I call to get data:

BYTE CBitmapFile::GetNextByte() {<br />
	BYTE data;<br />
	//fscanf(bmpFP, "%c", &data);<br />
	data = getc(bmpFP);<br />
	nBytesRead++;<br />
	nVerticalPosition++;<br />
	nCurrentPosition = ftell(bmpFP);<br />
	//CheckAlignment();<br />
	return data;<br />
}

I used fscanf, I'm trying to use file streams now but even after I include ifstream, fstream or anything else to try, the compiler still doesn't know what ifstream is even though I can hover the cursor over it and then start to use it and VS brings up that little class object list as I type.

Here's where I actually use the function. At this time I am only spitting the data back into another file for debug purposes but I'll eventually put the data into a CByteArray and then transmit it.

FILE * outFP = fopen("debug.dat", "w");<br />
for (int i=0; i<PacketSize; i++) {<br />
byte = BitmapFileReader->GetNextByte();<br />
//fputc(byte, outFP);<br />
fprintf(outFP, "%c", byte);<br />
}

PacketSize will almost always be 64. That for loop is inside a larger loop to keep going until it's created every packet. It's real simple, I can change functions to read the data, but I still get the same irregularities.

namaskaaram12-Apr-05 21:20

namaskaaram

12-Apr-05 21:20

hmmm.....i dunno if thiz will help.....tis JUST a guezz.....
u see when the command that u have given

bmpFP = fopen((LPCTSTR)fileName, "r");
FILE * outFP = fopen("debug.dat", "w");

both of openz in the text mode.....u have to specfy as.....

bmpFP = fopen((LPCTSTR)fileName, "rb");
FILE * outFP = fopen("debug.dat", "wb");

becoz when it openz in text mode certain characters are not accepted by the fopen(read the documentation relating that)for example i had done thiz encrypting code on a file,when opened in text mode and when ever it encounters the 26(ascii) value it(foperationz exit like as though end of file has reached!) stopz!basically i didnt know why....but then after a long search just by putting a "b" solved my prob!

ps:i dunno if thiz will help(might sound real stupid though,but could be the cause!)even i read filez using the basic file operationz.....itz fun though it can get hectic at timez..... D'Oh! | :doh:

cheerz..... Big Grin | :-D

"faith, hope, love remain, these three.....; but the greatest of these is love" -1 Corinthians 13:13

LighthouseJ13-Apr-05 4:01

13-Apr-05 4:01

You're now my new best friend.

I was looking into ifstream as a replacement to file pointers and ran across an option to change to a binary mode which is what I wanted but I never got it to fly. However, you pointed out that I can do that within file pointers which is mindlessly easy and simple fix. Although the file pointer irregularities are still puzzling why it did what it did, it now doesn't do that anymore with the binary mode used. You made my day, thanks a lot.

Blake Miller13-Apr-05 7:12

Blake Miller

13-Apr-05 7:12

I think in the 'old days' a ^Z character used to signify the end of text in a text file, even if the file size was larger than that. So, when you had opened your file in 'text' mode, it read until it reached a ^Z (26) character.