i have an interesting problem in my delphi 2009 app. when run in the debugger, i get an AV between the subroutine’s Begin keyword and the first statement. i believe that’s when it’s setting up local variables. here’s the information shown in the debugger:
uDeviceModule.pas.940: begin // _GetMeasurementsForChannel
00AF24C8 55 push ebp
00AF24C9 8BEC mov ebp,esp
00AF24CB 51 push ecx
00AF24CC B9E9A90100 mov ecx,$0001a9e9 // isn't this a lot for the stack?
// error happens in here
00AF24D1 6A00 push $00
00AF24D3 6A00 push $00
00AF24D5 49 dec ecx
00AF24D6 75F9 jnz $00af24d1
00AF24D8 874DFC xchg [ebp-$04],ecx
00AF24DB 53 push ebx
00AF24DC 894DF4 mov [ebp-$0c],ecx
00AF24DF 8955FC mov [ebp-$04],edx
00AF24E2 8945F8 mov [ebp-$08],eax
00AF24E5 33C0 xor eax,eax
00AF24E7 55 push ebp
00AF24E8 687D2FAF00 push $00af2f7d
00AF24ED 64FF30 push dword ptr fs:[eax]
00AF24F0 648920 mov fs:[eax],esp
uDeviceModule.pas.941: SelectChannel(eChannelNum); // first statement
this is a simplified version of this nested subroutine (see below).
procedure TDeviceModule.GetMeasurements(ExpInfo:TExpInfo;
_DisplayList:TMeasDisplayListAncestor; eExposureStatus:TExposureStatus;
bActiveErrorEnabled:boolean);
procedure _GetMeasurementsForChannel(_DisplayList:TObjectList;
eChannelNum:TDeviceChannelNum; eExposureStatus:TMyEnum;
bActiveErrorEnabled:boolean);
var
// these are all objects (not records)
selChannel:TDeviceChannel;
det:TDeviceDetector;
shoKVMeas:TStoMeasurement;
begin // ********************* error happens on this line
SelectChannel(eChannelNum);
_GetMeasurement(ExpInfo, _DisplayList, eChannelNum, eExposureStatus, ctdVal1);
_GetMeasurement(ExpInfo, _DisplayList, eChannelNum, eExposureStatus, ctdVal2);
_GetMeasurement(ExpInfo, _DisplayList, eChannelNum, eExposureStatus, ctdVal3);
end; // _GetMeasurementsForChannel
begin
// blah blah blah
_GetMeasurementsForChannel(_DisplayList,
eChannelNum,
eExposureStatus,
bActiveErrorEnabled);
// blah blah blah
end;
it is a single-threaded app.
how would you suggest i go about finding the cause of this problem? my first thoughts were:
1) increase max stack size–i did but it didn’t change anything. now it’s $160000 (1441792) but before this i think it was $150000.
2) is this object still valid? seems to be…it responds to the ClassName method correctly & FastMM doesn’t warn me about any problems.
interestingly, the stack trace makes no mention of the routine where the problem is caused.
:7e42b35c USER32.MoveWindow + 0xbe
:7e4565b7 USER32.GetRawInputDeviceInfoW + 0x5f
:7e428eec ; C:\WINDOWS\system32\USER32.dll
:7c90e473 ntdll.KiUserCallbackDispatcher + 0x13
ActnMenus.CallWindowHook(???,0,$31104)
:7e42b372 USER32.MoveWindow + 0xd4
:7e4565b7 USER32.GetRawInputDeviceInfoW + 0x5f
:7e428eec ; C:\WINDOWS\system32\USER32.dll
:7c90e473 ntdll.KiUserCallbackDispatcher + 0x13
:007b882d aqDockingWndProcHook + $1D
:7e42b372 USER32.MoveWindow + 0xd4
:7e4565b7 USER32.GetRawInputDeviceInfoW + 0x5f
:7e428eec ; C:\WINDOWS\system32\USER32.dll
:7c90e473 ntdll.KiUserCallbackDispatcher + 0x13
:7e428dd9 USER32.DefWindowProcW + 0xb9
:7e428d77 USER32.DefWindowProcW + 0x57
:7e418734 USER32.GetDC + 0x6d
:7e418816 ; C:\WINDOWS\system32\USER32.dll
:7e42a013 USER32.IsWindowUnicode + 0xa1
:7e42a039 USER32.CallWindowProcW + 0x1b
Controls.TWinControl.DefaultHandler(???)
:0050fac8 TWinControl.DefaultHandler + $DC
:0050b4b9 TControl.WndProc + $2D5
:0050f9cc TWinControl.WndProc + $518
:0050f0e3 TWinControl.MainWndProc + $2F
:0048874e StdWndProc + $16
:7e418734 USER32.GetDC + 0x6d
:7e418816 ; C:\WINDOWS\system32\USER32.dll
:7e428ea0 ; C:\WINDOWS\system32\USER32.dll
:7e428eec ; C:\WINDOWS\system32\USER32.dll
:7c90e473 ntdll.KiUserCallbackDispatcher + 0x13
:7e428dd9 USER32.DefWindowProcW + 0xb9
:7e428d77 USER32.DefWindowProcW + 0x57
:7e418734 USER32.GetDC + 0x6d
:7e418816 ; C:\WINDOWS\system32\USER32.dll
:7e42a013 USER32.IsWindowUnicode + 0xa1
:7e42a039 USER32.CallWindowProcW + 0x1b
:0050fac8 TWinControl.DefaultHandler + $DC
:0050f9cc TWinControl.WndProc + $518
:0050f0e3 TWinControl.MainWndProc + $2F
:0048874e StdWndProc + $16
:7e418734 USER32.GetDC + 0x6d
:7e418816 ; C:\WINDOWS\system32\USER32.dll
:7e428ea0 ; C:\WINDOWS\system32\USER32.dll
:7e428eec ; C:\WINDOWS\system32\USER32.dll
:7c90e473 ntdll.KiUserCallbackDispatcher + 0x13
:7e428dd9 USER32.DefWindowProcW + 0xb9
:7e428d77 USER32.DefWindowProcW + 0x57
:7e418734 USER32.GetDC + 0x6d
:7e418816 ; C:\WINDOWS\system32\USER32.dll
:7e42a013 USER32.IsWindowUnicode + 0xa1
:7e42a039 USER32.CallWindowProcW + 0x1b
:0050fac8 TWinControl.DefaultHandler + $DC
:0050f9cc TWinControl.WndProc + $518
:0050f0e3 TWinControl.MainWndProc + $2F
:0048874e StdWndProc + $16
:7e418734 USER32.GetDC + 0x6d
:7e418816 ; C:\WINDOWS\system32\USER32.dll
:7e428ea0 ; C:\WINDOWS\system32\USER32.dll
:7e428eec ; C:\WINDOWS\system32\USER32.dll
:7c90e473 ntdll.KiUserCallbackDispatcher + 0x13
:7e428dd9 USER32.DefWindowProcW + 0xb9
:7e428d77 USER32.DefWindowProcW + 0x57
:7e418734 USER32.GetDC + 0x6d
:7e418816 ; C:\WINDOWS\system32\USER32.dll
:7e42a013 USER32.IsWindowUnicode + 0xa1
:7e42a039 USER32.CallWindowProcW + 0x1b
:0050fac8 TWinControl.DefaultHandler + $DC
:0050f9cc TWinControl.WndProc + $518
:0065279d TcxControl.WndProc + $121
:0070b38d TcxCustomGrid.WndProc + $5
:0048874e StdWndProc + $16
:7e418734 USER32.GetDC + 0x6d
:7e418816 ; C:\WINDOWS\system32\USER32.dll
:7e428ea0 ; C:\WINDOWS\system32\USER32.dll
:7e428eec ; C:\WINDOWS\system32\USER32.dll
:7c90e473 ntdll.KiUserCallbackDispatcher + 0x13
:7e428dd9 USER32.DefWindowProcW + 0xb9
:7e428d77 USER32.DefWindowProcW + 0x57
:7e418734 USER32.GetDC + 0x6d
:7e418816 ; C:\WINDOWS\system32\USER32.dll
:7e42a013 USER32.IsWindowUnicode + 0xa1
:7e42a039 USER32.CallWindowProcW + 0x1b
:0050fac8 TWinControl.DefaultHandler + $DC
:0050f9cc TWinControl.WndProc + $518
:0065279d TcxControl.WndProc + $121
:0075bbc4 TcxGridSite.WndProc + $20
:0048874e StdWndProc + $16
:7e418734 USER32.GetDC + 0x6d
:7e418816 ; C:\WINDOWS\system32\USER32.dll
:7e428ea0 ; C:\WINDOWS\system32\USER32.dll
:7e428eec ; C:\WINDOWS\system32\USER32.dll
:7c90e473 ntdll.KiUserCallbackDispatcher + 0x13
:0044c91e HandleException + $22A
:004539af InterceptAHandleExcept + $3F
:0048874e StdWndProc + $16
:7e418734 USER32.GetDC + 0x6d
:7e418816 ; C:\WINDOWS\system32\USER32.dll
:7e4189cd ; C:\WINDOWS\system32\USER32.dll
:7e418a10 USER32.DispatchMessageW + 0xf
this suggests to me that the problem is stack overrun of some kind–bashing things used by message handling.
suggestions??? THANK YOU!
From your comment (“error happens here”) your error pops up in the loop that sets up stack space, all 212 Kb of it! It has absolutely nothing to do with the parameters you’re passing to the procedure and nothing to do with the viability of the object you’re passing as a parameter (there’s no CALL over there, it’s just an JNZ that loops to the PUSH $00 thing until the DEC ECX operation marks the ZERO flag, that is, $1a9e9 times).
Since you’re dealing with a procedure that uses 212Kb of stack space maybe you should try increasing the stack space by a lot more! Even better, figure out why your procedure is using up that much space and figure out if other procedures are in the same situation (look out for large Records used as local variables).