I am sorry to multiply my reports, but the "memory issues" correspond to different cases.
[2020-11-05 02:29:17.195,353] [Z_STACK/READ] INFO : Client Read: (len 4): [2020-11-05 02:29:17.195,654] [Z_STACK/LSTN] INFO : [MUTEX] Unlock SRSP Mutex [2020-11-05 02:29:17.195,804] [Z_STACK/LSTN] DEBUG : --> status failed: cmdID:14, status: 3 [2020-11-05 02:29:17.196,111] [Z_STACK/LSTN] INFO : ...sent 8 bytes to Client [2020-11-05 02:29:17.196,299] [Z_STACK/LSTN] INFO : !Done [2020-11-05 02:29:17.196,561] [NWK_MGR/READ] INFO : Received 4 bytes, subSys 0x71, cmdId 0x0D [2020-11-05 02:29:17.196,825] [NWK_MGR/READ] INFO : [MUTEX] SRSP Cond signal set [2020-11-05 02:29:17.196,924] [NWK_MGR/READ] INFO : Client Read: (len 8): [2020-11-05 02:29:17.197,201] [NWK_MGR/MAIN] INFO : [MUTEX] Unlock SRSP Mutex [2020-11-05 02:29:17.197,414] [NWK_MGR/MAIN] INFO : TX power set to 3 (nearest supported value) [2020-11-05 02:29:17] ================================================================= [2020-11-05 02:29:17] ==895==ERROR: AddressSanitizer: global-buffer-overflow on address 0x0025335f at pc 0x0006049b bp 0xbee056b8 sp 0xbee056bc [2020-11-05 02:29:17] READ of size 1 at 0x0025335f thread T0 [2020-11-05 02:29:17] #0 0x60499 in sdb_get_record ../sdb/SimpleDB.c:637 [2020-11-05 02:29:17] #1 0x63d27 in sdbtGetRecordCount ../sdb/SimpleDBTxt.c:79 [2020-11-05 02:29:17] #2 0x57ca5 in nwkMgrDb_Init .../3rdparty/ti/Zigbee_3_0_Linux_Gateway_1_0_1/source/Projects/zstack/linux/nwkmgr/nwkmgrdatabase.c:127 [2020-11-05 02:29:17] #3 0x44601 in nmInit .../3rdparty/ti/Zigbee_3_0_Linux_Gateway_1_0_1/source/Projects/zstack/linux/nwkmgr/nwkmgrsrv.c:745 [2020-11-05 02:29:17] #4 0x4401b in appInitPhase3 .../3rdparty/ti/Zigbee_3_0_Linux_Gateway_1_0_1/source/Projects/zstack/linux/nwkmgr/nwkmgrsrv.c:581 [2020-11-05 02:29:17] #5 0x99e5b in main ../srvwrapper/main.c:154 [2020-11-05 02:29:17] #6 0xb6d6dcf7 in __libc_start_main (/lib/libc.so.6+0x16cf7) [2020-11-05 02:29:17] [2020-11-05 02:29:17] 0x0025335f is located 54 bytes to the right of global variable 'tempfilename' defined in '../sdb/SimpleDB.c:494:15' (0x2532c0) of size 105 [2020-11-05 02:29:17] 0x0025335f is located 1 bytes to the left of global variable 'rec' defined in '../sdb/SimpleDB.c:596:15' (0x253360) of size 500 [2020-11-05 02:29:17] SUMMARY: AddressSanitizer: global-buffer-overflow ../sdb/SimpleDB.c:637 sdb_get_record [2020-11-05 02:29:17] Shadow bytes around the buggy address: [2020-11-05 02:29:17] 0x2004a610: f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 [2020-11-05 02:29:17] 0x2004a620: f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 [2020-11-05 02:29:17] 0x2004a630: f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 [2020-11-05 02:29:17] 0x2004a640: 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9 [2020-11-05 02:29:17] 0x2004a650: 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00 [2020-11-05 02:29:17] =>0x2004a660: 00 00 00 00 00 01 f9 f9 f9 f9 f9[f9]00 00 00 00 [2020-11-05 02:29:17] 0x2004a670: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [2020-11-05 02:29:17] 0x2004a680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [2020-11-05 02:29:17] 0x2004a690: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [2020-11-05 02:29:17] 0x2004a6a0: 00 00 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 [2020-11-05 02:29:17] 0x2004a6b0: 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 [2020-11-05 02:29:17] Shadow byte legend (one shadow byte represents 8 application bytes): [2020-11-05 02:29:17] Addressable: 00 [2020-11-05 02:29:17] Partially addressable: 01 02 03 04 05 06 07 [2020-11-05 02:29:17] Heap left redzone: fa [2020-11-05 02:29:17] Heap right redzone: fb
This happened in
if ( db->type == SDB_TYPE_TEXT )
{
// find the first record that matches the criteria
while ( (!found) && (fgets( rec, sizeof( rec ), db->file ) != NULL) )
{
db->last_accessed_record_start_file_pointer = _context;
db->last_accessed_record_size = db->get_record_size( rec );
_context = ftell( db->file );
if ( rec[strlen( rec ) - 1] != '\n' )
{
sdb_unlock( db );
return NULL;
}
on the "rec[strlen( rec ) - 1]" access.
my guess is that strlen(rec) is 0.
The CSV file was corrupted. In 'vi', the 'DbDeviceInfo.csv' contents shows like this:
Device Database
IeeeAddress,NwkAddress,Status,MfgId,EP_Count,ParentIeeeAddress,CapInfo
70:B3:D5:B1:30:01:01:1E , 0x102B , 0x01, 0x1234 , 1, 00:12:4B:00:10:22:82:77, 0x0C
CC:CC:CC:FF:FE:3A:2F:33 , 0xD5C6 , 0x01, 0x1246 , 1, 00:12:4B:00:10:22:82:77, 0x00
# 00:0D:6F:00:0E:8A:75:6F , 0xF842 , 0x00, 0x1163 , 1, 00:12:4B:00:10:22:82:77, 0xBE
00:12:4B:00:21:27:E4:CF , 0x8B0B , 0x00, 0x0000 , 1, 00:12:4B:00:10:22:82:77, 0xBE
# 00:0D:6F:00:0E:8A:75:6F , 0xF842 , 0x00, 0x1163 , 1, 00:12:4B:00:10:22:82:77, 0x00
00:0D:6F:00:0E:8A:75:6F , 0xF842 , 0x00, 0x1163 , 1, 00:12:4B:00:10:22:82:77, 0x00
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
I've seen this kind of contents before, so I'll ad a test on strlen strnlen to avoid this from happening again as well as avoid going beyond the size of the buffer while getting the string length.
