Re: [xml] Problems register memory callback routines via xmlMemSetup()

[Igor Zlatkovic <igor stud fh-frankfurt de>]

Hi there.

My greatest efforts were not sufficient to reproduce the failure you have
described. I have used 2.4.6 binary, however.

Now, either there was a problem and it has been fixed, or a problem lurks
somewhere in your code, for example inside the testOpenDocument function,
which appears on your stack trace. The failed assertion you see indicates a
problem such as freeing the same memory twice.

It does not matter which C-runtime library you have used. It is ony
important that libxml and your application link against the same C-runtime.
I have used the 'multithreaded dll' one.

I would say, try the version 2.4.6. If the problem persists, contact your
system administrator or technical support representative, hehe... Seriously,
check if it works with 2.4.6 and if not, double-check your code. If the
assertion still fails, send me the source code of the smallest programme
which demonstrates the problem.

Ciao
Igor


----- Original Message -----
From: "Henke, Markus" <Markus_Henke ordat com>
To: <xml gnome org>
Sent: Monday, October 15, 2001 3:05 PM
Subject: [xml] Problems register memory callback routines via xmlMemSetup()


Hello,

as a first step to use customized memory callback routines i've redefined
the default callbacks, that is:

===========================================================
static void testFreeFunc(void* ptr) {
  free(ptr);
}


static void *testMallocFunc(size_t size) {
  return malloc(size);
}


static void *testReallocFunc(void* ptr, size_t size) {
  return realloc(ptr, size);
}


static char *testStrdupFunc(const char* str) {
  return _strdup(str);
}
===========================================================


and register them via

===========================================================
xmlMemSetup(testFreeFunc, testMallocFunc, testReallocFunc, testStrdupFunc);
===========================================================


When i try to run my testprog, i get a debug-assertion:

===========================================================
Debug Assertion failed!

Program: ...
File: dbgheap.c
Line: 1044

Expression: _CrtIsValidHeapPointer(pUserData)
...
===========================================================


Call stack is:

===========================================================
_free_dbg_lk(void * 0x007c5fa8, int 1) line 1044 + 48 bytes
_free_dbg(void * 0x007c5fa8, int 1) line 1001 + 13 bytes
free(void * 0x007c5fa8) line 956 + 11 bytes
testFreeFunc(void * 0x007c5fa8) line 2137 + 12 bytes
xmlParserInputBufferGrow(_xmlParserInputBuffer * 0x007c4a68, int 493) line
2110 + 12 bytes
xmlParserInputGrow(_xmlParserInput * 0x007c5f20, int 250) line 1017 + 15
bytes
xmlParseDocument(_xmlParserCtxt * 0x007c5b30) line 7378 + 43 bytes
testOpenDocument(char * 0x007c25c8, long * 0x0012ff6c, long * 0x0012ff60)
line 392 + 11 bytes
main(int 2, char * * 0x007c2580) line 189 + 23 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e87d08()
===========================================================


That's quite strange for me since the callbacks are identical to the default
memory routines
and the memory interface of libxml2 is unmistakably how to register them.
I'm really get stucked here...  8(

I'm using libxml2-2.4.2 (some reasons for havn't updating yet...) on Win2K,
MS-VC++ 6.0,
testProg and libxml2 are both compiled against the "debug multithreaded DLL"
C- runtime.
Is this a known issue (and maybe solved in the most recent version) or is it
my mistake
(won't be the first time...   8) ?


Thanx in advance!

Mit freundlichen Gruessen - Kind regards
Markus Henke



________________________Addressed by:________________________
 ORDAT GmbH & Co. KG  -  Serversystems / eCom
 Dipl.-Inf. (FH) Markus Henke  Fon: +49 (641) 7941-0
 Rathenaustr. 1                Fax: +49 (641) 7941-132
 35394 Gießen                  mailto:markus henke ordat com
 See:                          http://www.ordat.com
_____________________________________________________________
              ...this behavior is by design...

 <<Markus Henke.vcf>>