excessive stack space usage in NTDLL
marcus at jet.franken.de
Mon Oct 3 08:09:13 CDT 2005
On Mon, Oct 03, 2005 at 02:36:55PM +0200, Alexandre Julliard wrote:
> Marcus Meissner <marcus at 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?
More information about the wine-devel