Problem description
in our distributed file storage， we use isa-l crc as data validation in file storage io . to be sure, we use the API as follows:
crc16_t10dif()
however, in our test，the API return error, and some partial stack information is as follows:
(gdb) bt
#0 0x00000000004404f4 in crc16_t10dif_by16_10()
#1 0x00007fdef2d86377 in hcrc_calc_csum16_inner (...)
...
The calling relationship of functions is: hcrc_calc_csum16_inner -- > crc16_t10dif -- > crc16_t10dif_by16_10
and，there is crc bug happens when performing file write operations.
But when we switch crc16_t10dif to crc16_t10dif_copy(), the program is OK
What a strange thing ???
now， we have 2 ideas as follows:
(1). the function crc16_t10dif has mistakes itself when using it, but we have no idea how it happens, e.g compile optimization;
(2). running error in crc16_t10dif maybe has relationship with our file storage business or something , however， we can't catch it.
So, we want to know， if somebody has meet the same questions ? thanks a lot.
Problem description in our distributed file storage， we use isa-l crc as data validation in file storage io . to be sure, we use the API as follows: crc16_t10dif() however, in our test，the API return error, and some partial stack information is as follows:
The calling relationship of functions is: hcrc_calc_csum16_inner -- > crc16_t10dif -- > crc16_t10dif_by16_10
and，there is crc bug happens when performing file write operations. But when we switch crc16_t10dif to crc16_t10dif_copy(), the program is OK What a strange thing ???
now， we have 2 ideas as follows: (1). the function crc16_t10dif has mistakes itself when using it, but we have no idea how it happens, e.g compile optimization; (2). running error in crc16_t10dif maybe has relationship with our file storage business or something , however， we can't catch it.
So, we want to know， if somebody has meet the same questions ? thanks a lot.