sending a text file from cosmos to cfs has failed due to size mismatch. about cf

[jphickey]

FWIW, this looks like a 64-bit translation issue. The old CF (incorrectly) defines its internal u_int_4 type as unsigned long int which is incorrect on a 64-bit CPU. So most likely it improperly converted a 32-bit value to unsigned long int and bad things happened. I don't think CF was ever test/qualified on a 64-bit CPU. If you need to use CF in the near term, probably best to build and run your entire CFE mission as 32-bit code.

There is an all-new version of CF under development, but hasn't been released yet. Once that is released I would expect it would be tested and validated on a 64-bit CPU as well.

[jphickey]

In a pinch, you also could try re-defining the internal types here:

CF/fsw/src/PUB/cfdp_config.h

Lines 46 to 72 in cbda7b9

	#ifndef boolean
	#define boolean unsigned char
	#endif
	#ifndef u_int_1
	#define u_int_1 unsigned char
	#endif
	#ifndef u_int_2
	#define u_int_2 unsigned int
	#endif
	#ifndef u_int_4
	#define u_int_4 unsigned long int
	#endif
	#ifndef s_int_1
	#define s_int_1 signed char
	#endif
	#ifndef s_int_2
	#define s_int_2 signed int
	#endif
	#ifndef s_int_4
	#define s_int_4 signed long int
	#endif

I would recommend to use the types provided in stdint.h -- as they are known to be the right size.

[harrypgh12]

Thanks for your help! cf/fsw/src/PUB/cfdp_config.h is the same in version 6.7 and 6.8.
The thing is that although my machine is 64 bit CPU, I don't have the same issue with version 6.7.

[harrypgh12]

I checked the size of u_int_4 and s_int_4. Both of them are 4 bytes. In stdint.h, the size of unit32_t and int32_t are also 4 bytes.

[jphickey]

I checked the size of u_int_4 and s_int_4. Both of them are 4 bytes. In stdint.h, the size of unit32_t and int32_t are also 4 bytes.

Interesting ... well the thing that suggested this (to me) was your log message in the original description. The value logged (8675833937941) is not representable in 32 bits - suggesting that somehow the m->eof.file_size has become a 64-bit quantity in your build.

When converted to hex this value is 7E400000015 ... and the 32 LSB's (00000015) translate to decimal "21" -- which looks like (potentially?) the correct length of your file. On a little endian machine this would be exactly the result if improperly casting a 32 bit quantity as a 64-bit, so you got the correct 32 LSBs but the upper bits had other info in them. So it really looks like this is what has happened.

[jphickey]

FWIW - converting the other value (mp->received_file_size) to hex yields F77AE078 -- which doesn't look like anything recognizable -- suggesting it was read from a completely incorrect location in memory or maybe uninitialized entirely. Another possibility is that whatever packet this came from was misaligned in memory and therefore when it was type cast and interpreted, it was completely wrong.

[harrypgh12]

One thing to mention. My coworker told me that I ran cfs v6.7 on a docker container which is 32 bit CPU. Now I am running cfs 6.8 on my 64 bit CPU machine without using the docker container. The reason that I didn't run v6.8 from the docker container was that it core-dumped by itself while up and running before I can send a file from cosmos.

And if I comment out the file size and checksum checking code in apps/cf/fsw/src/PRI/aaa.c, I can send the same text file from cosmos to cfs.

[harrypgh12]

It turns out that the problem stemmed from the endian-ness difference. The ground software sent the data in big endian and cFS took it as in little endian. I used ntohs(PduHdrPtr->PDataLen) to deal with the issue in apps/cf/fsw/src/cf_app.c. The problem was fixed!

[skliper]

Closing as obsolete (applies to v2.X)