| 2009-04-13 12:49:45 |
jvr |
description |
1)
Using
Description: Ubuntu jaunty (development branch)
Release: 9.04
2)
libxerces-c28:
Version: 2.8.0-3
Candidate: 2.8.0-3
Version Table:
*** 2.8.0-3 0
500 http://cz.archive.ubuntu.com jaunty/universe Packages
100 /var/lib/dpkg/status
libicu38:
Version: 3.8.1-3ubuntu1
Candidate: 3.8.1-3ubuntu1
Version Table:
*** 3.8.1-3ubuntu1 0
500 http://cz.archive.ubuntu.com jaunty/main Packages
100 /var/lib/dpkg/status
3)
Well I expected no leaks just because with my onw compile of latest xerces there was not any problem (leak).
4)
There are two metods in xerces-c:
one to initialize
XMLPlatformUtils::Initialize();
and
XMLPlatformUtils::Terminate();
to free all allocated memory.
But there is probably bug in the second one because it does not free all memory allocated by the first so..
I got some leaks while checking my program with valgrind and I'm convinced theese are not my mistake:
==9794== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 10 from 1)
==9794== malloc/free: in use at exit: 112 bytes in 2 blocks.
==9794== malloc/free: 433,757 allocs, 433,755 frees, 24,443,224 bytes allocated.
==9794== For counts of detected errors, rerun with: -v
==9794== searching for pointers to 2 not-freed blocks.
==9794== checked 351,936 bytes.
==9794==
==9794== 112 bytes in 2 blocks are still reachable in loss record 1 of 1
==9794== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==9794== by 0x6180239: UDataMemory_createNewInstance_3_8 (udatamem.c:45)
==9794== by 0x617EBD0: setCommonICUData (udata.c:119)
==9794== by 0x617F03D: openCommonData (udata.c:750)
==9794== by 0x617F1B6: doLoadFromCommonData (udata.c:1100)
==9794== by 0x617F72E: doOpenChoice (udata.c:1359)
==9794== by 0x618C5B1: haveAliasData (ucnv_io.c:245)
==9794== by 0x618C768: ucnv_io_countKnownConverters_3_8 (ucnv_io.c:1075)
==9794== by 0x617E11F: u_init_3_8 (uinit.c:88)
==9794== by 0x50019B6: xercesc_2_8::ICUTransService::ICUTransService() (in /usr/lib/libxerces-c.so.28.0)
==9794== by 0x5017732: xercesc_2_8::XMLPlatformUtils::makeTransService() (in /usr/lib/libxerces-c.so.28.0)
==9794== by 0x5029214: xercesc_2_8::XMLPlatformUtils::Initialize(char const*, char const*, xercesc_2_8::PanicHandler*, xercesc_2_8::MemoryManager*, bool) (in /usr/lib/libxerces-c.so.28.0)
==9794==
==9794== LEAK SUMMARY:
==9794== definitely lost: 0 bytes in 0 blocks.
==9794== possibly lost: 0 bytes in 0 blocks.
==9794== still reachable: 112 bytes in 2 blocks.
==9794== suppressed: 0 bytes in 0 blocks.
This seems like problem between xerces-c and libicu.
I was not able to find debug package for xerces so the trace for bug in xerces is not full. |
1)
Using
Description: Ubuntu jaunty (development branch)
Release: 9.04
2)
libxerces-c28:
Version: 2.8.0-3
Candidate: 2.8.0-3
Version Table:
*** 2.8.0-3 0
500 http://cz.archive.ubuntu.com jaunty/universe Packages
100 /var/lib/dpkg/status
libicu38:
Version: 3.8.1-3ubuntu1
Candidate: 3.8.1-3ubuntu1
Version Table:
*** 3.8.1-3ubuntu1 0
500 http://cz.archive.ubuntu.com jaunty/main Packages
100 /var/lib/dpkg/status
3)
Well I expected no leaks just because with my own compile of latest xerces there was not any problem (leak).
4)
There are two metods in xerces-c:
one to initialize
XMLPlatformUtils::Initialize();
and
XMLPlatformUtils::Terminate();
to free all allocated memory.
But there is probably bug in the second one because it does not free all memory allocated by the first so..
I got some leaks while checking my program with valgrind and I'm convinced theese are not my mistake:
==9794== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 10 from 1)
==9794== malloc/free: in use at exit: 112 bytes in 2 blocks.
==9794== malloc/free: 433,757 allocs, 433,755 frees, 24,443,224 bytes allocated.
==9794== For counts of detected errors, rerun with: -v
==9794== searching for pointers to 2 not-freed blocks.
==9794== checked 351,936 bytes.
==9794==
==9794== 112 bytes in 2 blocks are still reachable in loss record 1 of 1
==9794== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==9794== by 0x6180239: UDataMemory_createNewInstance_3_8 (udatamem.c:45)
==9794== by 0x617EBD0: setCommonICUData (udata.c:119)
==9794== by 0x617F03D: openCommonData (udata.c:750)
==9794== by 0x617F1B6: doLoadFromCommonData (udata.c:1100)
==9794== by 0x617F72E: doOpenChoice (udata.c:1359)
==9794== by 0x618C5B1: haveAliasData (ucnv_io.c:245)
==9794== by 0x618C768: ucnv_io_countKnownConverters_3_8 (ucnv_io.c:1075)
==9794== by 0x617E11F: u_init_3_8 (uinit.c:88)
==9794== by 0x50019B6: xercesc_2_8::ICUTransService::ICUTransService() (in /usr/lib/libxerces-c.so.28.0)
==9794== by 0x5017732: xercesc_2_8::XMLPlatformUtils::makeTransService() (in /usr/lib/libxerces-c.so.28.0)
==9794== by 0x5029214: xercesc_2_8::XMLPlatformUtils::Initialize(char const*, char const*, xercesc_2_8::PanicHandler*, xercesc_2_8::MemoryManager*, bool) (in /usr/lib/libxerces-c.so.28.0)
==9794==
==9794== LEAK SUMMARY:
==9794== definitely lost: 0 bytes in 0 blocks.
==9794== possibly lost: 0 bytes in 0 blocks.
==9794== still reachable: 112 bytes in 2 blocks.
==9794== suppressed: 0 bytes in 0 blocks.
This seems like problem between xerces-c and libicu.
I was not able to find debug package for xerces so the trace for bug in xerces is not full. |
|
