aerospike_key_get() 中的分段错误
Segmentation Fault in aerospike_key_get()
我正在使用 Aerospike 的 C 客户端库。给定的代码给我带来了很多麻烦：
RtCliErrors RtZonalDao::rtDispZonalCodes(char * p_ZnCodeListName, vector <struct RtDispRgZnCode> & dispRgZnCodeVec)
{
printf("\n[%s::%d] === Inside rtDispZonalCodes() === \n",__FILE__,__LINE__);
as_error l_asError;
as_key l_key ;
as_record l_rec;
try{
if(aerospike_cluster_is_connected(&RtDbConnection::ms_aerospikeIns) == true)
{
printf("\n[%s::%d] === aerospike connection OK ===",__FILE__,__LINE__);
}
else{
printf("\n[%s::%d] aerospike is not connected",__FILE__,__LINE__);
return RT_FAILURE;
}
if(p_ZnCodeListName==NULL)
{
printf("\n[%s::%d] Error: Null value of ZnCodeListName \n",__FILE__,__LINE__);
return RT_FAILURE;
}
if(p_ZnCodeListName!=NULL&&p_ZnCodeListName[0]==0)
{
printf("\n[%s::%d] Error: Null value of ZnCodeListName \n",__FILE__,__LINE__);
return RT_FAILURE;
}
as_key_init_str(&l_key, "bar", "rg_zn_cd_list_id_name", p_ZnCodeListName);
printf("\n[%s::%d] Key initialised successfully\n",__FILE__,__LINE__);
as_record* p_rec=&l_rec;
if (aerospike_key_exists(&RtDbConnection::ms_aerospikeIns, &l_asError, NULL, &l_key, &p_rec) == AEROSPIKE_ERR_RECORD_NOT_FOUND)
{
as_record_destroy(&l_rec);
as_key_destroy(&l_key);
printf("\n[ %s::%d ]--> Exception: , RG_ZN_CD_LIST not present in Db\n",__FILE__,__LINE__);
return RT_RG_ZN_CD_LST_NOT;
}
else
printf("\n[%s::%d] Primary Key found\n",__FILE__,__LINE__);
if (aerospike_key_get(&RtDbConnection::ms_aerospikeIns, &l_asError, NULL, &l_key, &p_rec) != AEROSPIKE_OK)
{
as_record_destroy(&l_rec);
as_key_destroy(&l_key);
printf("\n[%s::%d] Exception! Error Code: %d, Error Msg: %s\n",__FILE__,__LINE__, l_asError.code, l_asError.message);
return RT_FAILURE;
}
printf("\n[%s::%d] Fetch success\n",__FILE__,__LINE__);
as_record_destroy(&l_rec);
as_key_destroy(&l_key);
return RT_SUCCESS;
}//end of try
catch(...)
{
printf("\n[%s::%d] Default Exeption Caught \n",__FILE__,__LINE__);
as_record_destroy(&l_rec);
as_key_destroy(&l_key);
return RT_FAILURE;
}
}
我已经束手无策了。我一直试图在我的客户端代码中找出问题，但仍然没有成功。我得到了奇怪的观察结果。上面的 API 第一次调用时运行良好，但是当我第二次调用它时出现分段错误。下面给出的是 Valgrind 输出的片段：
==14471== Conditional jump or move depends on uninitialised value(s)
==14471== at 0x4A0A965: memcpy (vg_replace_strmem.c:1023)
==14471== by 0x4E77C4B: as_command_parse_bins (as_command.c:985)
==14471== by 0x4E7805E: as_command_parse_result (as_command.c:1167)
==14471== by 0x4E787D2: as_command_execute (as_command.c:492)
==14471== by 0x4E6DF22: aerospike_key_get (aerospike_key.c:136)
==14471== by 0x4042D0: RtZonalDao::rtDispZonalCodes(char*, std::vector<RtDispRgZnCode, std::allocator<RtDispRgZnCode> >&) (RtZonalDao.cpp:90)
==14471== by 0x404679: RtZonalDao::rtAddRgZnCodeToList(RtRgZonalCodes*, char*) (RtZonalDao.cpp:370)
==14471== by 0x407665: RtZonalDaoTest::rtAdd() (RtZonalDaoTest.cpp:94)
==14471== by 0x403134: main (RtMain.cpp:194)
==14471== Uninitialised value was created by a stack allocation
==14471== at 0x4041A8: RtZonalDao::rtDispZonalCodes(char*, std::vector<RtDispRgZnCode, std::allocator<RtDispRgZnCode> >&) (RtZonalDao.cpp:24)
==14471==
==14471== Use of uninitialised value of size 8
==14471== at 0x4A0A9AB: memcpy (vg_replace_strmem.c:1023)
==14471== by 0x4E77C4B: as_command_parse_bins (as_command.c:985)
==14471== by 0x4E7805E: as_command_parse_result (as_command.c:1167)
==14471== by 0x4E787D2: as_command_execute (as_command.c:492)
==14471== by 0x4E6DF22: aerospike_key_get (aerospike_key.c:136)
==14471== by 0x4042D0: RtZonalDao::rtDispZonalCodes(char*, std::vector<RtDispRgZnCode, std::allocator<RtDispRgZnCode> >&) (RtZonalDao.cpp:90)
==14471== by 0x404679: RtZonalDao::rtAddRgZnCodeToList(RtRgZonalCodes*, char*) (RtZonalDao.cpp:370)
==14471== by 0x407665: RtZonalDaoTest::rtAdd() (RtZonalDaoTest.cpp:94)
==14471== by 0x403134: main (RtMain.cpp:194)
==14471== Uninitialised value was created by a stack allocation
==14471== at 0x4041A8: RtZonalDao::rtDispZonalCodes(char*, std::vector<RtDispRgZnCode, std::allocator<RtDispRgZnCode> >&) (RtZonalDao.cpp:24)
==14471==
==14471== Invalid write of size 8
==14471== at 0x4A0A9AB: memcpy (vg_replace_strmem.c:1023)
==14471== by 0x4E77C4B: as_command_parse_bins (as_command.c:985)
==14471== by 0x4E7805E: as_command_parse_result (as_command.c:1167)
==14471== by 0x4E787D2: as_command_execute (as_command.c:492)
==14471== by 0x4E6DF22: aerospike_key_get (aerospike_key.c:136)
==14471== by 0x4042D0: RtZonalDao::rtDispZonalCodes(char*, std::vector<RtDispRgZnCode, std::allocator<RtDispRgZnCode> >&) (RtZonalDao.cpp:90)
==14471== by 0x404679: RtZonalDao::rtAddRgZnCodeToList(RtRgZonalCodes*, char*) (RtZonalDao.cpp:370)
==14471== by 0x407665: RtZonalDaoTest::rtAdd() (RtZonalDaoTest.cpp:94)
==14471== by 0x403134: main (RtMain.cpp:194)
==14471== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==14471==
==14471==
==14471== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==14471== Access not within mapped region at address 0x0
==14471== at 0x4A0A9AB: memcpy (vg_replace_strmem.c:1023)
==14471== by 0x4E77C4B: as_command_parse_bins (as_command.c:985)
==14471== by 0x4E7805E: as_command_parse_result (as_command.c:1167)
==14471== by 0x4E787D2: as_command_execute (as_command.c:492)
==14471== by 0x4E6DF22: aerospike_key_get (aerospike_key.c:136)
==14471== by 0x4042D0: RtZonalDao::rtDispZonalCodes(char*, std::vector<RtDispRgZnCode, std::allocator<RtDispRgZnCode> >&)
(RtZonalDao.cpp:90)
==14471== by 0x404679: RtZonalDao::rtAddRgZnCodeToList(RtRgZonalCodes*, char*) (RtZonalDao.cpp:370)
==14471== by 0x407665: RtZonalDaoTest::rtAdd() (RtZonalDaoTest.cpp:94)
==14471== by 0x403134: main (RtMain.cpp:194)
==14471== If you believe this happened as a result of a stack
==14471== overflow in your program's main thread (unlikely but
==14471== possible), you can try to increase the size of the
==14471== main thread stack using the --main-stacksize= flag.
==14471== The main thread stack size used in this run was 10485760.
==14471==
==14471== HEAP SUMMARY:
==14471== in use at exit: 248,960 bytes in 70 blocks
==14471== total heap usage: 126 allocs, 56 frees, 260,256 bytes allocated
Is there any problem in any part of the code I’ve provided above?
似乎在 Aerospike forum 上提出了同样的问题并在那里得到了回答。我建议要么不要在两个频道上交叉发布，要么如果这样做，请在两侧提供交叉链接。
我正在使用 Aerospike 的 C 客户端库。给定的代码给我带来了很多麻烦：
RtCliErrors RtZonalDao::rtDispZonalCodes(char * p_ZnCodeListName, vector <struct RtDispRgZnCode> & dispRgZnCodeVec)
{
printf("\n[%s::%d] === Inside rtDispZonalCodes() === \n",__FILE__,__LINE__);
as_error l_asError;
as_key l_key ;
as_record l_rec;
try{
if(aerospike_cluster_is_connected(&RtDbConnection::ms_aerospikeIns) == true)
{
printf("\n[%s::%d] === aerospike connection OK ===",__FILE__,__LINE__);
}
else{
printf("\n[%s::%d] aerospike is not connected",__FILE__,__LINE__);
return RT_FAILURE;
}
if(p_ZnCodeListName==NULL)
{
printf("\n[%s::%d] Error: Null value of ZnCodeListName \n",__FILE__,__LINE__);
return RT_FAILURE;
}
if(p_ZnCodeListName!=NULL&&p_ZnCodeListName[0]==0)
{
printf("\n[%s::%d] Error: Null value of ZnCodeListName \n",__FILE__,__LINE__);
return RT_FAILURE;
}
as_key_init_str(&l_key, "bar", "rg_zn_cd_list_id_name", p_ZnCodeListName);
printf("\n[%s::%d] Key initialised successfully\n",__FILE__,__LINE__);
as_record* p_rec=&l_rec;
if (aerospike_key_exists(&RtDbConnection::ms_aerospikeIns, &l_asError, NULL, &l_key, &p_rec) == AEROSPIKE_ERR_RECORD_NOT_FOUND)
{
as_record_destroy(&l_rec);
as_key_destroy(&l_key);
printf("\n[ %s::%d ]--> Exception: , RG_ZN_CD_LIST not present in Db\n",__FILE__,__LINE__);
return RT_RG_ZN_CD_LST_NOT;
}
else
printf("\n[%s::%d] Primary Key found\n",__FILE__,__LINE__);
if (aerospike_key_get(&RtDbConnection::ms_aerospikeIns, &l_asError, NULL, &l_key, &p_rec) != AEROSPIKE_OK)
{
as_record_destroy(&l_rec);
as_key_destroy(&l_key);
printf("\n[%s::%d] Exception! Error Code: %d, Error Msg: %s\n",__FILE__,__LINE__, l_asError.code, l_asError.message);
return RT_FAILURE;
}
printf("\n[%s::%d] Fetch success\n",__FILE__,__LINE__);
as_record_destroy(&l_rec);
as_key_destroy(&l_key);
return RT_SUCCESS;
}//end of try
catch(...)
{
printf("\n[%s::%d] Default Exeption Caught \n",__FILE__,__LINE__);
as_record_destroy(&l_rec);
as_key_destroy(&l_key);
return RT_FAILURE;
}
}
我已经束手无策了。我一直试图在我的客户端代码中找出问题，但仍然没有成功。我得到了奇怪的观察结果。上面的 API 第一次调用时运行良好，但是当我第二次调用它时出现分段错误。下面给出的是 Valgrind 输出的片段：
==14471== Conditional jump or move depends on uninitialised value(s)
==14471== at 0x4A0A965: memcpy (vg_replace_strmem.c:1023)
==14471== by 0x4E77C4B: as_command_parse_bins (as_command.c:985)
==14471== by 0x4E7805E: as_command_parse_result (as_command.c:1167)
==14471== by 0x4E787D2: as_command_execute (as_command.c:492)
==14471== by 0x4E6DF22: aerospike_key_get (aerospike_key.c:136)
==14471== by 0x4042D0: RtZonalDao::rtDispZonalCodes(char*, std::vector<RtDispRgZnCode, std::allocator<RtDispRgZnCode> >&) (RtZonalDao.cpp:90)
==14471== by 0x404679: RtZonalDao::rtAddRgZnCodeToList(RtRgZonalCodes*, char*) (RtZonalDao.cpp:370)
==14471== by 0x407665: RtZonalDaoTest::rtAdd() (RtZonalDaoTest.cpp:94)
==14471== by 0x403134: main (RtMain.cpp:194)
==14471== Uninitialised value was created by a stack allocation
==14471== at 0x4041A8: RtZonalDao::rtDispZonalCodes(char*, std::vector<RtDispRgZnCode, std::allocator<RtDispRgZnCode> >&) (RtZonalDao.cpp:24)
==14471==
==14471== Use of uninitialised value of size 8
==14471== at 0x4A0A9AB: memcpy (vg_replace_strmem.c:1023)
==14471== by 0x4E77C4B: as_command_parse_bins (as_command.c:985)
==14471== by 0x4E7805E: as_command_parse_result (as_command.c:1167)
==14471== by 0x4E787D2: as_command_execute (as_command.c:492)
==14471== by 0x4E6DF22: aerospike_key_get (aerospike_key.c:136)
==14471== by 0x4042D0: RtZonalDao::rtDispZonalCodes(char*, std::vector<RtDispRgZnCode, std::allocator<RtDispRgZnCode> >&) (RtZonalDao.cpp:90)
==14471== by 0x404679: RtZonalDao::rtAddRgZnCodeToList(RtRgZonalCodes*, char*) (RtZonalDao.cpp:370)
==14471== by 0x407665: RtZonalDaoTest::rtAdd() (RtZonalDaoTest.cpp:94)
==14471== by 0x403134: main (RtMain.cpp:194)
==14471== Uninitialised value was created by a stack allocation
==14471== at 0x4041A8: RtZonalDao::rtDispZonalCodes(char*, std::vector<RtDispRgZnCode, std::allocator<RtDispRgZnCode> >&) (RtZonalDao.cpp:24)
==14471==
==14471== Invalid write of size 8
==14471== at 0x4A0A9AB: memcpy (vg_replace_strmem.c:1023)
==14471== by 0x4E77C4B: as_command_parse_bins (as_command.c:985)
==14471== by 0x4E7805E: as_command_parse_result (as_command.c:1167)
==14471== by 0x4E787D2: as_command_execute (as_command.c:492)
==14471== by 0x4E6DF22: aerospike_key_get (aerospike_key.c:136)
==14471== by 0x4042D0: RtZonalDao::rtDispZonalCodes(char*, std::vector<RtDispRgZnCode, std::allocator<RtDispRgZnCode> >&) (RtZonalDao.cpp:90)
==14471== by 0x404679: RtZonalDao::rtAddRgZnCodeToList(RtRgZonalCodes*, char*) (RtZonalDao.cpp:370)
==14471== by 0x407665: RtZonalDaoTest::rtAdd() (RtZonalDaoTest.cpp:94)
==14471== by 0x403134: main (RtMain.cpp:194)
==14471== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==14471==
==14471==
==14471== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==14471== Access not within mapped region at address 0x0
==14471== at 0x4A0A9AB: memcpy (vg_replace_strmem.c:1023)
==14471== by 0x4E77C4B: as_command_parse_bins (as_command.c:985)
==14471== by 0x4E7805E: as_command_parse_result (as_command.c:1167)
==14471== by 0x4E787D2: as_command_execute (as_command.c:492)
==14471== by 0x4E6DF22: aerospike_key_get (aerospike_key.c:136)
==14471== by 0x4042D0: RtZonalDao::rtDispZonalCodes(char*, std::vector<RtDispRgZnCode, std::allocator<RtDispRgZnCode> >&)
(RtZonalDao.cpp:90)
==14471== by 0x404679: RtZonalDao::rtAddRgZnCodeToList(RtRgZonalCodes*, char*) (RtZonalDao.cpp:370)
==14471== by 0x407665: RtZonalDaoTest::rtAdd() (RtZonalDaoTest.cpp:94)
==14471== by 0x403134: main (RtMain.cpp:194)
==14471== If you believe this happened as a result of a stack
==14471== overflow in your program's main thread (unlikely but
==14471== possible), you can try to increase the size of the
==14471== main thread stack using the --main-stacksize= flag.
==14471== The main thread stack size used in this run was 10485760.
==14471==
==14471== HEAP SUMMARY:
==14471== in use at exit: 248,960 bytes in 70 blocks
==14471== total heap usage: 126 allocs, 56 frees, 260,256 bytes allocated
Is there any problem in any part of the code I’ve provided above?
似乎在 Aerospike forum 上提出了同样的问题并在那里得到了回答。我建议要么不要在两个频道上交叉发布，要么如果这样做，请在两侧提供交叉链接。