19515c4899
* harbour/contrib/hbmxml/hbmxml.c
! redesigned to use mxml_node reference counters - it should fix
all problems with memory leak and accessing freed memory which
where in our wrapper.
! fixed few typos and possible GPF I've found
! modified mxmlDelete() wrapper to respect reference counter
It means that it cannot call mxmlDelete() MXML function directly.
- removed mxmlRelease() and mxmlRetain() PRG wrappers
* harbour/contrib/hbmxml/3rd/minixml/mxml_fil.c
! fixed double mxml_node releasing
* harbour/contrib/hbmxml/3rd/minixml/mxml_nod.c
! fixed mxmlDelete() to respect reference counters
; TODO: There are still two problems but inside MXML library.
1. memory leak in testmxml rem_err.xml
The leak is inside MXML function and have to be fixed by author
(I do not want to change this code too deeply). Here is valgrind
report:
(88 direct, 1 indirect) bytes in 1 blocks are definitely lost
at 0x4C234E7: calloc ()
by 0x40ABF9: mxml_new (mxml_nod.c:758)
by 0x40AE39: mxmlNewText (mxml_nod.c:547)
by 0x407421: mxml_load_data (mxml_fil.c:1585)
by 0x404E50: HB_FUN_MXMLLOADFILE (hbmxml.c:794)
by 0x50A9FF6: hb_vmProc (hvm.c:5795)
by 0x5086104: hb_vmExecute (hvm.c:1655)
by 0x50A9FF6: hb_vmProc (hvm.c:5795)
by 0x50ADC12: main (mainstd.c:96)
2. Index functions in MXML library does not update reference counters.
It means that it's possible to create index then remove nodes and
access such nodes extracting their addresses from the index.
It's the only one place I know when user can make sth wrong with
memory using just modified HBMXML wrapper and it cannot be fixed
without modifications in MXML library.
Please test it.