Access of unallocated memory - realloc fails

[r]

test_main.c (attached) sometimes crashes at the marked realloc().

I write "sometimes" because I cannot reproduce the crash in all environments. The memory manager seems to be play an important role.

One system (not C) with thorough memory checking reports that the memory footer has been corrupted with each run in both Win32 and Win64. This could be due to a memory underrun in NMEProcess(). Unfortunately I can not tell where it happens because no stack trace is generated.

With C I do not have the same memory checking available. test_main.c crashes in Win64 mode. Win32 runs fine. No further details available, I'm afraid.

Could anyone test the scenario with Valgrind or similar and share the results?

The attached _Debug_Bug.txt file must be binary identical, otherwise it does not trigger the error. To ensure that this is the case I attached it ZIP compressed.

[Yves Piguet (yves-piguet)]

Thank you very much for the test files, Ralf. I think I've managed to reproduce the bug with gcc and gdb:

- Compile with gcc -g test_main.c NME.c
- Debug with gdb a.out
- Put a breakpoint, step after the second malloc
- Put a watchoint at the end of ConvBuf with watch ConvBuf[ConvBufLen]
- Step until you execute NMEProcess the first time (with n, no need to step in with s)

You'll get a buffer overflow:
Hardware watchpoint 3: ConvBuf[ConvBufLen]

Old value = 0 '\0'
New value = 120 'x'
0x00000001000067e2 in addLinkBegin (isImage=0, styleStack=0x7fff5fbff304, styleNesting=0x7fff5fbff300, i0=337, outputFormat=0x7fff5fbff590, context=0x7fff5fbff258) at NME.c:2099
2099 context->dest[context->destLen++] = context->src[context->linkOffset + k];

Backtrace:

#0 0x00000001000067e2 in addLinkBegin (isImage=0, styleStack=0x7fff5fbff304, styleNesting=0x7fff5fbff300, i0=337, outputFormat=0x7fff5fbff590, context=0x7fff5fbff258) at NME.c:2099
#1 0x000000010000c65c in NMEProcess (nmeText=0x100100080 "* Optimizing '~/~/' in XPath expressions.\r\n* Expose [[xmlBufShrink]] in the public tree API.\r\n* Visible HTML elements close the head tag.\r\n* Fix file and line report for XSD SAX and reader streaming v"..., nmeTextLen=385, buf=0x100801000 "* Optimizing '~/~/' in XPath expressions.\r\n* Expose [[xmlBufShrink]] in the public tree API.\r\n* Visible HTML elements close the head tag.\r\n* Fix file and line report for XSD SAX and reader streaming v"..., bufSize=1794, options=0, eol=0x1000119ab "\r\n", outputFormat=0x7fff5fbff590, fontSize=0, output=0x7fff5fbff838, outputLen=0x7fff5fbff84c, outputUCS16Len=0x0) at NME.c:3379
#2 0x00000001000010ef in main (argc=1, argv=0x7fff5fbff8a8) at test_main.c:36

[Yves Piguet (yves-piguet)]

Suggested fix in NME.c (insert the two-line buffer overflow check at line 2099):

@@ -2096,6 +2096,8 @@
       outputFormat->encodeCharData));
    else
    {
+ if (context->destLen + 1 > context->bufSize)
+ return kNMEErrNotEnoughMemory;
     context->dest[context->destLen++] = context->src[context->linkOffset + k];
     if (isFirstUTF8Byte(context->src[context->linkOffset + k]))
      context->destLenUCS16++;

[r (ralfjunker)]

On 17.12.2012 16:57, Yves Piguet wrote:

> Suggested fix in NME.c (insert the two-line buffer overflow check at
> line 2099):

Yes, Yves, this fixes it. realloc() works fine now on all my systems.

Many thanks for the speedy fix!

Ralf