Re: excessive stack space usage in NTDLL

[Marcus Meissner]

On Mon, Oct 03, 2005 at 02:36:55PM +0200, Alexandre Julliard wrote:
> Marcus Meissner <marcus(a)jet.franken.de> writes:
> > No recursion as far as I can see. I get this backtrace:
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 1469332400 (LWP 24408)]
> > 0x5577e57d in wine_cp_wcstombs (table=0x5586e668, flags=0, src=0x57845114, srclen=Cannot access memory at address 0x57845078
> > ) at wctomb.c:181
> > 181         case 7:  dst[-7]  = uni2cp_low[uni2cp_high[src[-7]  >> 8] + (src[-7]  & 0xff)];
> > (gdb) bt
> > #0  0x5577e57d in wine_cp_wcstombs (table=0x5586e668, flags=0, src=0x57845114, srclen=Cannot access memory at address 0x57845078
> > ) at wctomb.c:181
> > #1  0x55725df1 in RtlUnicodeToOemN (dst=0x57845188 "#", dstlen=7, reslen=0x0, src=0x57845114, srclen=14) at rtlstr.c:845
> > #2  0x557271f5 in RtlUpcaseUnicodeStringToCountedOemString (oem=0x57845194, uni=0x57845250, doalloc=Cannot access memory at address 0x57845113
> > ) at rtlstr.c:1127
> > #3  0x5571964c in RtlIsNameLegalDOS8Dot3 (unicode=0x57845250, oem=0x0, spaces=0x5784524f "W\016") at path.c:909
> > #4  0x55705055 in wine_nt_to_unix_file_name (nameW=0x578458f4, unix_name_ret=0x57845830, disposition=1, check_case=Cannot access memory at address 0x5784524e
> > ) at directory.c:1162
> > #5  0x55709ccd in NtQueryFullAttributesFile (attr=0x578458dc, info=0x57845854) at file.c:1388
> > #6  0x55709ecc in NtQueryAttributesFile (attr=0x578458dc, info=0x578458b4) at file.c:1436
> > #7  0x55a266bb in GetFileAttributesW (name=0x57842c00) at file.c:1772
> > #8  0x55a26756 in GetFileAttributesA (name=0x57c7fec8 "C:\\Windows\\Temp\\ACDLABS 8.0 (FREE)") at file.c:1793
> >
> > (gdb) x /i $eip
> > 0x5577e57d <wine_cp_wcstombs+2957>:     mov    %edx,0xffffff40(%ebp)
> > (gdb) (gdb) print $ebp-0xc0
> > $4 = (void *) 0x57844ff8
> > (gdb)
> >
> > cat /proc/../maps excerpt:
> >   57842000-57844000 rwxp 57842000 00:00 0
> >   57844000-57845000 ---p 57844000 00:00 0
> >   57845000-57944000 rwxp 57845000 00:00 0	(1MB stack)
> >   579c5000-57a1c000 rwxp 579c5000 00:00 0
> >   57a20000-57c80000 rwxp 57a20000 00:00 0
> >
> > It just underflowed the 1MB stackspace here.
> >
> > But the above backtrace only has 2kb of stackspace usage, true.
>
> Something else must be using the rest of the stack, unless the initial
> stack pointer was set wrong, which seems unlikely. Probably the app
> was not compiled with frame pointer and gdb can't get a backtrace.
> Does winedbg show anything different?

I guess the app itself uses so much stuff.

There is a lot more backtrace below, but just hexcode.
I stopped scrolling after 20000 entries.

Can I do winedbg do follow CreateProcess()es? Or attach it
to running wines by just knowing the PID?

Ciao, Marcus

excessive stack space usage in NTDLL

[Eric Pouech]

> I guess the app itself uses so much stuff.
>
> There is a lot more backtrace below, but just hexcode.
> that's (likely) because you don't have debug info for the app
> I stopped scrolling after 20000 entries.
>
> Can I do winedbg do follow CreateProcess()es? 
> this hasn't been fully tested, I don't recommend it
> Or attach it
> to running wines by just knowing the PID?
> yes, attach <pid> works fine (you can use info proc to get the list of 
> running processes, except the debugger where you key the commands=

A+
-- 
Eric Pouech