Re: trap in malloc on 2000 terminal server

From: Ivan Brugiolo [MSFT] (ivanbrug_at_online.microsoft.com)
Date: 10/20/04 

Date: Wed, 20 Oct 2004 10:58:36 -0700

For the error in the debugger extension, looks like you have an old debugger
package.
Please update to a recent ones. 6.3.17 should be the latest public version.

#1 it means something like
WCHAR * p = malloc(MAX_PATH);
wcscpy(p,StringWayLongerThanMaxPath);

#2 string conversion happens under-the cover before calling certain APIs
and in way too many circumstances to be listed in any comprehensive manner.

#3 That is the expected behavior per standard, unless you perform
some operation that has an undefined behavior beforehand.
For example, writing past the end of an allocated buffer has undefined
behavior.
Writing at a memory address returned to the free
store via free() has undefined behavior.
A conformant C implementation could format your hard
drive when an undefined behavior is encountered.
On average, heap corruption shows up as crashes in random places,
like your case below.

#4 adding code to "circumvent" the problem is the worst short-leged
solution you can think of. Hiding the problem just delays the discovery
of the root cause, and can only cause more undefined behaviors.
It's not a probelm of failing the memory allocation in that spot.
You should realize first that any operation in the C-Rutnime heap
will have undefined bahaviors from that point on.
Just to make this clear: an averge complex application with
pseudo-robustness achieved via __try/__except everywhere
can hide few hundres exceptions caused by heap corruption.
But, at a certain point, it will either hung or hard crash.

#5 debugging a heap corruption without heap instrumentation is
not easy. I gave suggestion on how to start attacking the problem.
You can enable light-page-heap, that is a reasonable compromise
between performance and effectiveness.
c:\debuggers>gflags.exe -p /enable YourApp.exe
and then you can set-up ADPlus.vbs to take a full dump of the process.

#6 NO. malloc should performed as specified by the standard,
and have undefiend behavior otherwise. If you want
such strong requirements from your memory allocator,
enable FullPageHeap, and use a debugger.
c:\debuggers>gflags.exe -p /enable YourApp.exe /full 

-- 
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Ramki" <Ramki@discussions.microsoft.com> wrote in message
news:6C351A93-4638-4F31-989D-4055C941386B@microsoft.com...
> Hi Ivan,
>
> Thanks for your inputs. We ran the "heap -p -all" command and we got an
> error saying
>
> "0:012> !heap -p -all
> No page heaps active in process (or bad symbols)"
>
> Please clarify the following doubts.
>
> 1. What does "Unicode String Heap Overrun" mean?
> 2. It is a legacy application and there is not Unicode support in this.
All
> the characters are native characters.
> 3. What is the logic of malloc? Is it not the responsibility of the malloc
> call to return a good valid address with which I can work or a NULL
pointer?
> 4. What is the code (other than exception handling) that I need to add to
> circumvent the trap and return an error code saying failed to allocate
memory
> to the callee .
> 5. This is happening at the customer's environment. The only possible set
of
> documents that I can get is dr. watson log and user dump. With the debug
> module the problem is not happening. Here we are not able to re-create the
> problem that the customer is experiencing. What is the best way to debug?
> 6. From the programming perspective, the malloc should take care of memory
> overrun as addressed below and not the application. Let us assume a case,
> like if I have received a valid pointer which has already been used by my
> application because of overrun. In this case also the possibility data
> corruption and it may trap only when I handle the data inappropriately. So
> our assumption is only due to invalid memory manipulation there might be a
> change of "access violation" but not with malloc itself.
>
> Your response is highly appreciated. Thanks in advance.
>
> Regards,
> Ramki
>
> "Ivan Brugiolo [MSFT]" wrote:
>
> > From the layout of your registers, looks like
> > a Unicode String Heap Overrun on the C-Runtime heap,
> > that (given the information availalbe) is not a bug in malloc,
> > but a generic bug in the application with manipulations
> > of buffers allocated from the C-Runtime heap.
> >
> > With some good luck, you might be able to find the
> > block that was overrun (look for "read memory errors" from
`!heap -p -all`)
> > and, with even more luck, the owner of that block.
> >
> >
> > -- 
> > This posting is provided "AS IS" with no warranties, and confers no
rights.
> > Use of any included script samples are subject to the terms specified at
> > http://www.microsoft.com/info/cpyright.htm
> >
> >
> > "ramki" <ramki@discussions.microsoft.com> wrote in message
> > news:AC00EB56-F6B4-400B-ADEC-29751B12AC77@microsoft.com...
> > > Hello,
> > >
> > > I received a dump from one of my customer and on debugging we found
that
> > the
> > > trap is occuring on one of function in MSVCRT module, which leads
caccess
> > > violation (Please refer call stack information below). we are just
calling
> > > malloc(size_t) from our application. The following are the details
> > received
> > > from dump.
> > >
> > > Windows 2000 Version 2195 UP Free x86 compatible
> > > Product: Server, suite: TerminalServer SingleUserTS
> > > Debug session time: Thu Oct 14 19:47:07 2004
> > > System Uptime: 0 days 0:09:06.165
> > > Process Uptime: not available
> > > Symbol search path is:
> > > srv*c:\temp\symbols*http://msdl.microsoft.com/download/symbols
> > > Executable search path is:
> > >
> >
............................................................................
.
> > ........
> > > (74c.7bc): Access violation - code c0000005 (!!! second chance !!!)
> > > eax=00440008 ebx=00000025 ecx=00000120 edx=00440052 esi=00900d78
> > edi=00900000
> > > eip=77fcc36d esp=0281fcb0 ebp=0281fe48 iopl=0         nv up ei pl nz
na pe
> > nc
> > > cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000
> > efl=00000202
> > > ntdll!RtlAllocateHeap+0xc3:
> > > *** WARNING: Unable to verify checksum for MSGIO.dll
> > > *** ERROR: Symbol file could not be found.  Defaulted to export
symbols
> > for
> > > MSGIO.dll -
> > > 77fcc36d 8842fe           mov     [edx-0x2],al
> > ds:0023:00440050=e9
> > > 0:012> kb
> > > ChildEBP RetAddr  Args to Child
> > > 0281fe48 78001532 00900000 00000000 00000120
ntdll!RtlAllocateHeap+0xc3
> > > 0281fe88 780014cf 0000011c 780014b8 0000011c MSVCRT!_heap_alloc+0xeb
> > > 0281fe90 780014b8 0000011c 00000000 002d5f3b MSVCRT!_nh_malloc+0x10
> > > *** ERROR: Symbol file could not be found.  Defaulted to export
symbols
> > for
> > > CSNIA.dll -
> > > 0281fe9c 002d5f3b 0000011c 002d64d4 01d29988 MSVCRT!malloc+0xf
> > > WARNING: Stack unwind information not available. Following frames may
be
> > > wrong.
> > > 0281fef4 002d1eb2 01d29988 01d31a20 01d31248
CSNIA!nia_route_deinit+0x4cab
> > > 01d31a20 0000e200 01d29348 01d29988 00000000
CSNIA!nia_route_deinit+0xc22
> > > 0:012> lm
> > > start    end        module name
> > > 00230000 0023a000   MESSAGE      (deferred)
> > > 00240000 00249000   NSTRC        (deferred)
> > > 00250000 00258000   MILLUTIL     (deferred)
> > > 00260000 00287000   MSGIO      C (export symbols)       MSGIO.dll
> > > 00290000 00296000   PCSW32X      (deferred)
> > > 002a0000 002a9000   CSCM         (deferred)
> > > 002b0000 002b6000   CSXLIB       (deferred)
> > > 002c0000 002ee000   CSNIA        (export symbols)       CSNIA.dll
> > > 002f0000 002f9000   CSLBA        (deferred)
> > > 00300000 00306000   SLPAPI       (deferred)
> > > 00310000 00316000   CSNLG        (deferred)
> > > 00320000 00337000   PCSCAPI      (deferred)
> > > 00400000 0040a000   csit         (deferred)
> > > 00410000 00520000   OOCSVCS2     (deferred)
> > > 00520000 00543000   PCSMFCX      (deferred)
> > > 00550000 00570000   NODEINIT     (deferred)
> > > 00570000 00582000   SPELLING     (deferred)
> > > 00590000 00596000   FMT_UTIL     (deferred)
> > > 005a0000 005b4000   VACGVERF     (deferred)
> > > 005c0000 005cd000   TRNSDT       (deferred)
> > > 005d0000 005e9000   IBMSLP       (deferred)
> > > 005f0000 00600000   WAPPC32      (deferred)
> > > 00600000 00608000   WINRUI32     (deferred)
> > > 00610000 00617000   CSQEL        (deferred)
> > > 00620000 0062a000   CSSMA        (deferred)
> > > 00630000 00642000   CSSEC        (deferred)
> > > 00650000 00655000   limgmt       (deferred)
> > > 00660000 00666000   CSUTLS       (deferred)
> > > 00a40000 00a4a000   PCMFCENU     (deferred)
> > > 00e60000 00f4c000   PCSCDRA      (deferred)
> > > 10000000 1000a000   CSTLM        (deferred)
> > > 10200000 10260000   MSVCRTD      (deferred)
> > > 11000000 11009000   WINNOF32     (deferred)
> > > 12000000 12008000   WPDAPI32     (deferred)
> > > 15000000 15011000   WINCSV32     (deferred)
> > > 16000000 16004000   CMNAPI32     (deferred)
> > > 17000000 17008000   WINMS32      (deferred)
> > > 55600000 5561d000   wspwsp       (deferred)
> > > 68590000 685a6000   rsvpsp       (deferred)
> > > 68c40000 68c49000   RAPILIB      (deferred)
> > > 690a0000 690ab000   PSAPI        (deferred)
> > > 6c370000 6c46b000   MFC42        (deferred)
> > > 70bd0000 70c35000   SHLWAPI      (deferred)
> > > 71710000 71794000   COMCTL32     (deferred)
> > > 74fd0000 74fee000   msafd        (deferred)
> > > 74ff0000 75002000   MSWSOCK      (pdb symbols)
> > > c:\temp\symbols\mswsock.pdb\3D77C4C51\mswsock.pdb
> > > 75010000 75017000   wshtcpip     (deferred)
> > > 75020000 75028000   WS2HELP      (deferred)
> > > 75030000 75044000   WS2_32       (deferred)
> > > 75050000 75058000   WSOCK32      (deferred)
> > > 75150000 7515f000   SAMLIB       (deferred)
> > > 75170000 751bf000   NETAPI32     (deferred)
> > > 751c0000 751c6000   NETRAP       (deferred)
> > > 75500000 75504000   security     (deferred)
> > > 77320000 77337000   MPRAPI       (deferred)
> > > 77340000 77353000   iphlpapi     (deferred)
> > > 77360000 77379000   DHCPCSVC     (deferred)
> > > 77380000 773a3000   ADSLDPC      (deferred)
> > > 773b0000 773df000   ACTIVEDS     (deferred)
> > > 77430000 77440000   MSASN1       (deferred)
> > > 77440000 774b8000   CRYPT32      (deferred)
> > > 774c0000 774d1000   RASMAN       (deferred)
> > > 774e0000 77513000   RASAPI32     (deferred)
> > > 77520000 77525000   ICMP         (deferred)
> > > 77530000 77552000   TAPI32       (deferred)
> > > 77570000 775a0000   WINMM        (deferred)
> > > 77830000 7783e000   RTUTILS      (deferred)
> > > 77880000 7790e000   SETUPAPI     (deferred)
> > > 77950000 7797a000   WLDAP32      (deferred)
> > > 77980000 779a4000   DNSAPI       (deferred)
> > > 779b0000 77a4b000   OLEAUT32     (deferred)
> > > 77a50000 77b47000   OLE32        (deferred)
> > > 77d30000 77da1000   RPCRT4       (deferred)
> > > 77e10000 77e75000   USER32       (deferred)
> > > 77f40000 77f7c000   GDI32        (deferred)
> > > 77f80000 77ffb000   ntdll        (pdb symbols)
> > > c:\temp\symbols\ntdll.pdb\3E5265273\ntdll.pdb
> > > 78000000 78045000   MSVCRT       (pdb symbols)
> > > c:\temp\symbols\msvcrt.pdb\3E6E31152\msvcrt.pdb
> > > 780a0000 780b2000   MSVCIRT      (deferred)
> > > 782d0000 782ef000   msv1_0       (deferred)
> > > 7c0f0000 7c152000   USERENV      (deferred)
> > > 7c2d0000 7c332000   ADVAPI32     (deferred)
> > > 7c340000 7c34f000   SECUR32      (deferred)
> > > 7c4e0000 7c599000   KERNEL32     (deferred)
> > >
> > > The offset 002d5f3b in csnia is part of our application, which maps to
the
> > > code NIAMALLOC(sizeof(SLIVCBx_t)) which is just malloc(0x11c).
> > >
> > > Does any such problem reported before with malloc function, which has
been
> > > fixed recently?
> > >
> > > Please clarify why the malloc traps with access violation. Also give
any
> > > additional inputs.
> > >
> > > Regards,
> > > Ramki
> >
> >
> >

Relevant Pages

  • Re: trap in malloc on 2000 terminal server
    ... For the error in the debugger extension, looks like you have an old debugger ... some operation that has an undefined behavior beforehand. ... On average, heap corruption shows up as crashes in random places, ... What is the logic of malloc? ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Weird strings getting written over each other
    ... > The debugger put things on the stack ... Even as a result of malloc? ... uses the heap? ...
    (microsoft.public.vc.language)
  • Re: Weird strings getting written over each other
    ... > The debugger put things on the stack ... Even as a result of malloc? ... uses the heap? ...
    (microsoft.public.dotnet.languages.vc)
  • Re: What does SZ on the ps output mean?
    ... originally assumed that no matter how many malloc and frees were done, ... there shouldn't be an upward trend. ... hope of spotting any memory leak. ... examine the java heap as mgd by the JVM. ...
    (comp.unix.solaris)
  • Re: Debuggers Kill Printing.
    ... debugger is attached I only see the crash after a break point ... Maybe you have some latent heap corruption that is exposed ... is this hypothesis consistent with the observation that when the debugger is attached I only see the crash after a break point? ... Does GDI make temporary allocations on the application's heap? ...
    (microsoft.public.development.device.drivers)
Loading