miloyip
commented
7 years ago Do the unit tests of RapidJSON have the same problem?
Open naveenbirru opened 7 years ago
miloyip
commented
7 years ago Do the unit tests of RapidJSON have the same problem?
I am seeing the following issue on Centos Linux:
Any idea how to debug further? I have used Gdb and valgrind. Please look at the below output
Program terminated with signal 11, Segmentation fault.
0 0x000000000043c93b in rapidjson::MemoryPoolAllocator::Malloc (this=0xef16bac, size=768)
172 /usr/local/include/rapidjson/allocators.h: No such file or directory. (gdb) bt
0 0x000000000043c93b in rapidjson::MemoryPoolAllocator::Malloc (this=0xef16bac, size=768)
1 0x000000000043b65d in rapidjson::GenericValue<rapidjson::UTF8, rapidjson::MemoryPoolAllocator >::AddMember (this=0xef16bb0,
2 0x000000000043a277 in rapidjson::GenericValue<rapidjson::UTF8, rapidjson::MemoryPoolAllocator >::AddMember (this=0xef16bb0,
Here is Valgrind output: ==17591== Memcheck, a memory error detector ==17591== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==17591== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==17591== Command: /usr/thales/centman/middleware/services/licensed ==17591== ==17591== (action at startup) vgdb me ... ==17591== ==17591== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==17591== /path/to/gdb /usr/thales/centman/middleware/services/licensed ==17591== and then give GDB the following command ==17591== target remote | /usr/lib64/valgrind/../../bin/vgdb --pid=17591 ==17591== --pid is optional if only one valgrind process is running ==17591== ==17591== Warning: ignored attempt to set SIGKILL handler in sigaction(); ==17591== the SIGKILL signal is uncatchable ==17618== ==17618== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==17618== /path/to/gdb /usr/thales/centman/middleware/services/licensed ==17618== and then give GDB the following command ==17618== target remote | /usr/lib64/valgrind/../../bin/vgdb --pid=17618 ==17618== --pid is optional if only one valgrind process is running ==17618== ==17591== ==17591== HEAP SUMMARY: ==17591== in use at exit: 0 bytes in 0 blocks ==17591== total heap usage: 1,273 allocs, 1,273 frees, 62,455 bytes allocated ==17591== ==17591== All heap blocks were freed -- no leaks are possible ==17591== ==17591== For counts of detected and suppressed errors, rerun with: -v ==17591== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) [root@jt-ct ~]# ==17618== Thread 6: ==17618== Invalid read of size 8 ==17618== at 0x43C93B: rapidjson::MemoryPoolAllocator::Malloc(unsigned long) (allocators.h:172)
==17618== by 0x43B65C: rapidjson::GenericValue<rapidjson::UTF8, rapidjson::MemoryPoolAllocator >::AddMember(rapidjson::GenericValue<rapidjson::UTF8, rapidjson::MemoryPoolAllocator >&, rapidjson::GenericValue<rapidjson::UTF8, rapidjson::MemoryPoolAllocator >&, rapidjson::MemoryPoolAllocator&) (document.h:943)
==17618== by 0x43A276: rapidjson::GenericValue<rapidjson::UTF8, rapidjson::MemoryPoolAllocator >::AddMember(rapidjson::GenericStringRef, rapidjson::GenericValue<rapidjson::UTF8, rapidjson::MemoryPoolAllocator >&, rapidjson::MemoryPoolAllocator&) (document.h:1024)
==17618== by 0x553A5E3: LogEvent::sendLogEvent(std::string, std::string, std::string, int, std::string, int, int, bool, void) (logevent.cpp:109)
==17618== by 0x553C28D: LogEvent::log(log4cxx::spi::LocationInfo const&, std::string, std::string, std::string, bool, std::string, int, void, int, int) (logevent.cpp:273)
==17618== by 0x714473C: clone (in /usr/lib64/libc-2.17.so)
==17618== Address 0x70000503000008 is not stack'd, malloc'd or (recently) free'd
==17618==