A memory bug

[jj2007]

I am very curious to see a comparison. Seriously - I'd love to speed up my RichMasm editor.

Simple,made test on your IDE changing the stack size with the linker,you will have an answer.

Good proposal. So here is the answer:
Loading a 13,000 lines source into a RichEdit control:
- stack 12 MB: 1.0 seconds
- stack 0.5 MB: 0.75 seconds

Your turn 8)

[MichaelW]

I can’t see any significant difference either. Running on my Windows XP P3 system, loading the current MASM32 windows.inc 10 times, whether I use the default stack size, or /STACK:10000000,10000000, I get ~1720ms.

Code: [Select]

;==============================================================================
; Build as a console app.
;==============================================================================
include \masm32\include\masm32rt.inc
;==============================================================================
IDC_RE equ 100
;==============================================================================

  ;----------------------------------------------------------------------
  ; This is a general-purpose control definition macro that adds support
  ; for controls of any type to the MASM32 In-Memory Dialogs. For this
  ; macro the control class is specified as a quoted string, instead of
  ; being hard coded.
  ;----------------------------------------------------------------------

    DlgControl MACRO quoted_caption,quoted_class,dstyle,tx,ty,wd,ht,ctlID
      align_4 edi
      mov DWORD PTR [edi+0],  WS_VISIBLE or WS_CHILD or dstyle
      mov WORD  PTR [edi+8],  tx
      mov WORD  PTR [edi+10], ty
      mov WORD  PTR [edi+12], wd
      mov WORD  PTR [edi+14], ht
      mov WORD  PTR [edi+16], ctlID
      add edi, 18
      ustring quoted_class
      ustring quoted_caption
      ;-------------------------------------------
      ; Advance edi past the creation data array.
      ;-------------------------------------------
      add edi, 2
    ENDM

;==============================================================================
    .data
      hInst       HMODULE 0
      hwndRE      HWND    0
      hFile       HANDLE  0
      flag        dd      0
      editstream  EDITSTREAM <1,,EditStreamCallback>
      filename    db      "\masm32\include\windows.inc",0
    .code
;==============================================================================

EditStreamCallback proc dwCookie:DWORD, pbBuff:DWORD, cb:DWORD, pcb:DWORD

    invoke ReadFile, hFile, pbBuff, cb, pcb, NULL
    xor eax, eax
    ret

EditStreamCallback endp

;==============================================================================

DlgProc proc hwndDlg:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM

    LOCAL rc:RECT

    SWITCH uMsg

        CASE WM_INITDIALOG

            invoke CreateFile, ADDR filename, GENERIC_READ, FILE_SHARE_READ,
                               NULL, OPEN_EXISTING, NULL, NULL
            mov hFile, eax

            invoke GetDlgItem, hwndDlg, IDC_RE
            mov hwndRE, eax

            invoke SendMessage, hwndRE, EM_EXLIMITTEXT, 1000000*10, 0

         CASE WM_SYSCOMMAND

            .IF flag == 0
                inc flag
                invoke GetTickCount
                push eax

                REPEAT 10
                    invoke SendMessage, hwndRE,
                                        EM_STREAMIN,
                                        SF_TEXT,
                                        ADDR editstream
                    invoke SetFilePointer, hFile, 0, NULL, FILE_BEGIN
                ENDM

                invoke GetTickCount
                pop edx
                sub eax, edx
                printf("%dms\n", eax)
            .ENDIF

        CASE WM_SIZE

            invoke GetClientRect, hwndDlg, ADDR rc
            invoke MoveWindow, hwndRE, 0, 0, rc.right, rc.bottom, TRUE

        CASE WM_COMMAND

            SWITCH wParam
                Case IDCANCEL
                    invoke CloseHandle,hFile
                    invoke EndDialog, hwndDlg, NULL
            ENDSW

        CASE WM_CLOSE

            invoke CloseHandle,hFile
            invoke EndDialog, hwndDlg, NULL

    EndSw

    return 0

DlgProc endp

;==============================================================================
start:
;==============================================================================

    invoke LoadLibrary, chr$("RICHED20.DLL")

    invoke GetModuleHandle, NULL
    mov hInst, eax

    Dialog  "Click title bar to start test", \
            "Courier New",8, \
            WS_OVERLAPPED or WS_SYSMENU or DS_CENTER, \
            1, \
            0,0,200,150, \
            1024

    DlgControl 0, \
               "RichEdit20A", \
               WS_VSCROLL or \
               WS_HSCROLL or \
               ES_SUNKEN or \
               ES_MULTILINE or \
               ES_AUTOVSCROLL or \
               ES_AUTOHSCROLL or \
               ES_NOHIDESEL or \
               ES_WANTRETURN, \
               0,0,0,0,IDC_RE

    CallModalDialog hInst, 0, DlgProc, NULL
    exit

;==============================================================================
end start

I didn’t think to test the effect of the RE control styles, and I am apparently testing a Rich Edit 3.0 control.

[jj2007]

I can’t see any significant difference either. Running on my Windows XP P3 system...

With Celeron M, XP SP3:
- 400k stack: 407 ms
- 8M stack: 407 ms

In fact, my own tests tell the same story (the 0.75 secs were an outlier ).

It is a nice habit to measure things instead of just declaring "truths" as if Moses himself had been giving a helping hand ;-)

[TouEnMasm]

It is a nice habit to measure things instead of just declaring "truths" as if Moses himself had been giving a helping hand ;-)

I have just declared truth in one particular case,not on all.
Everybody can test it if it is usefull or not in his case.

[hutch--]

There is an image you regularly get in medieval movies in times of plague where lines of pilgrims walk along the streets chanting and self flagelating and every time I have read this thread the image comes back to me. In 32 bit PE executables that stack is set by the linker and is part of the OS design, it is not a dynamic resizable stack. Now while there are various reasons why you vary these two parameters, upwards for recursion or downwards if a particular application must have the smallest memory footprint possible, trying to dynamically size the stack looks and sounds like those folks of long ago who deliberately harm themselves.

[dedndave]

there are times when the amount of stack space required is not known until runtime
i don't see any harm in probing the stack to increase the space available by TIB.StackLimit

In 32 bit PE executables that stack is set by the linker and
is part of the OS design, it is not a dynamic resizable stack.

i would say it's dynamic, as the OS continually balances the need for stack space with the need for heap space

[TouEnMasm]

Make this simple test ,put in the WM_DESTROY message and you will see the amount of stack memory reserved dynamically by the system .
On my XP SP3 it start at 3000h bytes,for my IDE it end at 16000h bytes

Take care with 64 bits there is a NT_TIB64:

Code: [Select]

NT_TIB64 STRUCT DEFALIGNMASM
ExceptionList QWORD ?
StackBase QWORD ?
StackLimit QWORD ?
SubSystemTib QWORD ?
IF DEFINED(_MSC_EXTENSIONS)
union
FiberData QWORD ?
Version DWORD ?
ENDS
ELSE
FiberData QWORD ?
ENDIF
ArbitraryUserPointer QWORD ?
Self QWORD ?
NT_TIB64 ENDS



Code: [Select]

WM_DESTROY
invoke StackSize
mov edx,eax
invoke BaseN,edx,16,addr ZoneMessagesErreurs
invoke MessageBox,NULL,ADDR ZoneMessagesErreurs,SADR("Taille Pile"),MB_OK

;################################################################
StackSize PROC
ASSUME  FS:Nothing
mov ecx,0
mov edx,FS:[ecx].NT_TIB.StackLimit ;FS:[8]
mov eax,FS:[ecx].NT_TIB.StackBase  ;FS:[4]
sub eax,edx  ;allocated stack
ASSUME  FS:ERROR
         ret
StackSize endp


[TouEnMasm]

Found where is the bug:
windbg give me

   ;MSVCR80!_chkstk+27 [crt\src\intel\chkstk.asm @ 99] 78131637 8500  test    dword ptr [eax],eax

The "chkstk.asm " is in the c++express crt source code.
Viewing it:

; Find next lower page and probe
cs20:
        sub     eax, _PAGESIZE_         ; decrease by PAGESIZE
        test    dword ptr [eax],eax     ; probe page.  <<< comment is clear
        jmp     short cs10

What i have done is just read the size of the stack at the end,using the openfile fialog.Size stack needed by the dialog in pages is 13 pages.
Now using the  dynamic  allocation of stack with virtualloc i choose 16 pages to allocate and no more bug with a right clic on a file.

This show that virtualloc uninstall the guard page interrupt  (_XCPT_GUARD_PAGE_VIOLATION).
If someone know how to reinstall it,put it here. (Found Virtual Protect PAGEGUARD)