I have an application that I have converted to Delphi 2009 I have "String format checking" On and the standard memory manager. I downloaded the MS debugging tools at http://www.microsoft.com/whdc/devtools/debugging/install64bit.mspx and got some debug files but I am not sure what to make of them. I would like some pointers on where to go from here. Below is the top part of the debug file (bottom has all the drivers loaded);
Opened log file 'c:\debuglog.txt'
1: kd> .sympath srv*c:\symbols*http://msdl.microsoft.com/downloads/symbols
Symbol search path is: srv*c:\symbols*http://msdl.microsoft.com/downloads/symbols
Expanded Symbol search path is: srv*c:\symbols*http://msdl.microsoft.com/downloads/symbols
1: kd> .reload;!analyze -v;r;kv;lmnt;.logclose;q
Loading Kernel Symbols
...............................................................
................................................................
.........................
Loading User Symbols
Loading unloaded module list
........
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000000000008, EXCEPTION_DOUBLE_FAULT
Arg2: 0000000080050033
Arg3: 00000000000006f8
Arg4: fffff80001ee1678
Debugging Details:
------------------
BUGCHECK_STR: 0x7f_8
CUSTOMER_CRASH_COUNT: 4
DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT
PROCESS_NAME: SomeApplication.e
CURRENT_IRQL: 1
EXCEPTION_RECORD: fffffa60087b43c8 -- (.exr 0xfffffa60087b43c8)
.exr 0xfffffa60087b43c8
ExceptionAddress: fffff80001ed0150 (nt!RtlVirtualUnwind+0x0000000000000250)
ExceptionCode: 10000004
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: 00000000000000d8
TRAP_FRAME: fffffa60087b4470 -- (.trap 0xfffffa60087b4470)
.trap 0xfffffa60087b4470
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000050 rbx=0000000000000000 rcx=0000000000000004
rdx=00000000000000d8 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80001ed0150 rsp=fffffa60087b4600 rbp=fffffa60087b4840
r8=0000000000000006 r9=fffff80001e4e000 r10=ffffffffffffff88
r11=fffff8000204c000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
nt!RtlVirtualUnwind+0x250:
fffff800`01ed0150 488b02 mov rax,qword ptr [rdx] ds:00000000`000000d8=????????????????
.trap
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff80001ea81ee to fffff80001ea8450
STACK_TEXT:
fffffa60`005f1a68 fffff800`01ea81ee : 00000000`0000007f 00000000`00000008 00000000`80050033 00000000`000006f8 : nt!KeBugCheckEx
fffffa60`005f1a70 fffff800`01ea6a38 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x6e
fffffa60`005f1bb0 fffff800`01ee1678 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0xb8
fffffa60`087b3c90 fffff800`01ea82a9 : fffffa60`087b43c8 00000000`00000001 fffffa60`087b4470 00000000`0000023b : nt!KiDispatchException+0x34
fffffa60`087b4290 fffff800`01ea70a5 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000001 : nt!KiExceptionDispatch+0xa9
fffffa60`087b4470 fffff800`01ed0150 : fffffa60`087b5498 fffffa60`087b4e70 fffff800`01f95190 fffff800`01e4e000 : nt!KiPageFault+0x1e5
fffffa60`087b4600 fffff800`01ed3f78 : fffffa60`00000001 00000000`00000000 00000000`00000000 ffffffff`ffffff88 : nt!RtlVirtualUnwind+0x250
fffffa60`087b4670 fffff800`01ee1706 : fffffa60`087b5498 fffffa60`087b4e70 fffffa60`00000000 00000000`00000000 : nt!RtlDispatchException+0x118
fffffa60`087b4d60 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDispatchException+0xc2
STACK_COMMAND: kb
FOLLOWUP_IP:
nt!KiDoubleFaultAbort+b8
fffff800`01ea6a38 90 nop
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: nt!KiDoubleFaultAbort+b8
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 49e0237f
FAILURE_BUCKET_ID: X64_0x7f_8_nt!KiDoubleFaultAbort+b8
BUCKET_ID: X64_0x7f_8_nt!KiDoubleFaultAbort+b8
Followup: MachineOwner
---------
rax=fffffa60005f1b70 rbx=fffffa60087b43c8 rcx=000000000000007f
rdx=0000000000000008 rsi=fffffa60087b4470 rdi=fffff80001f9bfa4
rip=fffff80001ea8450 rsp=fffffa60005f1a68 rbp=fffffa60005f1c30
r8=0000000080050033 r9=00000000000006f8 r10=fffff80001ee1678
r11=fffffa60087b4468 r12=0000000000000000 r13=fffffa60087b4290
r14=fffff8000205149c r15=fffff80001e4e000
iopl=0 nv up ei ng nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00000282
nt!KeBugCheckEx:
fffff800`01ea8450 48894c2408 mov qword ptr [rsp+8],rcx ss:0018:fffffa60`005f1a70=000000000000007f
Child-SP RetAddr : Args to Child : Call Site
fffffa60`005f1a68 fffff800`01ea81ee : 00000000`0000007f 00000000`00000008 00000000`80050033 00000000`000006f8 : nt!KeBugCheckEx
fffffa60`005f1a70 fffff800`01ea6a38 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x6e
fffffa60`005f1bb0 fffff800`01ee1678 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0xb8 (TrapFrame # fffffa60`005f1bb0)
fffffa60`087b3c90 fffff800`01ea82a9 : fffffa60`087b43c8 00000000`00000001 fffffa60`087b4470 00000000`0000023b : nt!KiDispatchException+0x34
fffffa60`087b4290 fffff800`01ea70a5 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000001 : nt!KiExceptionDispatch+0xa9
fffffa60`087b4470 fffff800`01ed0150 : fffffa60`087b5498 fffffa60`087b4e70 fffff800`01f95190 fffff800`01e4e000 : nt!KiPageFault+0x1e5 (TrapFrame # fffffa60`087b4470)
fffffa60`087b4600 fffff800`01ed3f78 : fffffa60`00000001 00000000`00000000 00000000`00000000 ffffffff`ffffff88 : nt!RtlVirtualUnwind+0x250
fffffa60`087b4670 fffff800`01ee1706 : fffffa60`087b5498 fffffa60`087b4e70 fffffa60`00000000 00000000`00000000 : nt!RtlDispatchException+0x118
fffffa60`087b4d60 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDispatchException+0xc2
The help file for windbg goes into some more detail on the various kernel mode bug checks, and what to do about them. I don't really know your level of expertise or what you are expecting here, but generally speaking nothing you can do in a user mode program such as delphi will ever cause a bug check. Therefore we would normally go with the assumption of a driver bug, or some kind of hardware failure.
I entered UNEXPECTED_KERNEL_MODE_TRAP into the help index and got this page:
Windows Driver Kit: Debugging Tools
Bug Check 0x7F:
UNEXPECTED_KERNEL_MODE_TRAP The
UNEXPECTED_KERNEL_MODE_TRAP bug check
has a value of 0x0000007F. This bug
check indicates that the Intel CPU
generated a trap and the kernel failed
to catch this trap.
This trap could be a bound trap (a
trap the kernel is not permitted to
catch) or a double fault (a fault that
occurred while processing an earlier
fault, which always results in a
system failure).
elided...
0x00000008, or Double Fault, indicates
that an exception occurs during a call
to the handler for a prior exception.
Typically, the two exceptions are
handled serially. However, there are
several exceptions that cannot be
handled serially, and in this
situation the processor signals a
double fault. There are two common
causes of a double fault:
A kernel
stack overflow. This overflow occurs
when a guard page is hit, and the
kernel tries to push a trap frame.
Because there is no stack left, a
stack overflow results, causing the
double fault. If you think this
overview has occurred, use !thread to
determine the stack limits, and then
use kb (Display Stack Backtrace) with
a large parameter (for example, kb
100) to display the full stack.
A
hardware problem.
Cause Bug check 0x7F typically occurs
after you install a faulty or
mismatched hardware (especially
memory) or if installed hardware
fails.
A double fault can occur when the
kernel stack overflows. This overflow
occurs if multiple drivers are
attached to the same stack. For
example, if two file system filter
drivers are attached to the same stack
and then the file system recurses back
in, the stack overflows.
elided...
It goes on into a lot more detail about that, and the various debugging techniques and what you can do to troubleshoot the problem.
Related
My customer is facing random crashes. And got multiple dumps from him but Unable to analyze the reason correctly. Crashes are on Windows Server 2008 and 2012.
he customer is running an application on a windows network:
Most users access to the application from their local clients (all Windows 10).
Some users are running the application via terminal servers (TS1 and TS2).
TS1 is a Windows Server 2008 R2.
TS2 is a Windows Server 2012 R2.
On TS1, TS2 and all Windows 10 PCs Actian PSQL Clients are installed (13.30.037.000).
A Windows Server 2012 R2 is used as a file and database server (Actian PSQL 13.31.006.000).
Windbg shows :
*** procdump -e -ma 7824 C:\Debugging
*** Unhandled exception: C0000005.ACCESS_VIOLATION'
!analyze -v shows :
GetUrlPageData2 (WinHttp) failed: 12002.
FAULTING_IP:
clr!DontCallDirectlyForceStackOverflow+12
74184c2a 0000 add byte ptr [eax],al
EXCEPTION_RECORD: 76ef042f -- (.exr 0x76ef042f)
ExceptionAddress: 0be13000
ExceptionCode: 0be03000
ExceptionFlags: 0be0b000
NumberParameters: 199442432
Parameter[0]: 0bef4000
Parameter[1]: 0bf09000
Parameter[2]: 0bf0c000
Parameter[3]: 0bf0f000
Parameter[4]: 0bf2d000
Parameter[5]: 0bf41000
Parameter[6]: 0bf46000
Parameter[7]: 0bf55000
Parameter[8]: 0bf5a000
Parameter[9]: 0bf62000
Parameter[10]: 0bf67000
Parameter[11]: 0bf82000
Parameter[12]: 0bfc3000
Parameter[13]: 0bfc7000
Parameter[14]: 0bfdf000
CONTEXT: 0b971530 -- (.cxr 0xb971530;r)
eax=000001ff ebx=01ffffff ecx=ffff0000 edx=00000000 esi=00000000 edi=0000003f
eip=003fffff esp=00000000 ebp=00000000 iopl=0 vip vif nv up di pl nz na po nc
cs=0000 ss=0000 ds=0000 es=0000 fs=ffff gs=0000 efl=ffff0000
0000:ffff ?? ???
Last set context:
eax=000001ff ebx=01ffffff ecx=ffff0000 edx=00000000 esi=00000000 edi=0000003f
eip=003fffff esp=00000000 ebp=00000000 iopl=0 vip vif nv up di pl nz na po nc
cs=0000 ss=0000 ds=0000 es=0000 fs=ffff gs=0000 efl=ffff0000
0000:ffff ?? ???
Resetting default scope
DEFAULT_BUCKET_ID: CODE_CORRUPTION
PROCESS_NAME: MgxpaRuntime.exe
ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.
EXCEPTION_PARAMETER1: 00000001
EXCEPTION_PARAMETER2: 0b9703bc
WRITE_ADDRESS: 0b9703bc
FOLLOWUP_IP:
clr!DontCallDirectlyForceStackOverflow+12
74184c2a 0000 add byte ptr [eax],al
APPLICATION_VERIFIER_FLAGS: 6aeef141
WARNING: !chkimg output was truncated to 50 lines. Invoke !chkimg without '-lo [num_lines]' to view entire output.
17666 errors : !clr (73cb1000-7440c927)
APP: mgxparuntime.exe
ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) x86fre
MANAGED_STACK: !dumpstack -EE
Failed to load data access DLL, 0x80004005
Some functionality may be impaired
OS Thread Id: 0x3d58 (9)
TEB information is not available so a stack size of 0xFFFF is assumed
Current frame:
ChildEBP RetAddr Caller, Callee
PRIMARY_PROBLEM_CLASS: CODE_CORRUPTION
BUGCHECK_STR: APPLICATION_FAULT_WRONG_SYMBOLS
LAST_CONTROL_TRANSFER: from 73fcb5b4 to 74184c2a
STACK_TEXT:
0b9713c0 73fcb5b4 92ca4142 0b971450 73db0690 clr!DontCallDirectlyForceStackOverflow+0x12
0b9713e8 73db062a 92ca469e 00b06970 00000000 clr!CLRVectoredExceptionHandler+0x9b
0b971434 76eb6822 0b971450 0b971580 0b971530 clr!CLRVectoredExceptionHandlerShim+0xd6
0b971484 76f1cfc1 00000000 0b971a78 091351a0 ntdll!RtlpCallVectoredHandlers+0xba
0b971514 0b9719e8 76ef042f 0b971530 0b971580 ntdll!RtlDispatchException+0x72
WARNING: Frame IP not in any known module. Following frames may be wrong.
0b971520 0b971580 0b971530 0b971580 c0000005 0xb9719e8
0b971530 00000000 00000000 74184c2a 00000002 0xb971580
STACK_COMMAND: ~9s; .ecxr ; kb
MODULE_NAME: memory_corruption
IMAGE_NAME: memory_corruption
FOLLOWUP_NAME: memory_corruption
DEBUG_FLR_IMAGE_TIMESTAMP: 0
MEMORY_CORRUPTOR: LARGE
BUCKET_ID: MEMORY_CORRUPTION_LARGE
FAILURE_BUCKET_ID: CODE_CORRUPTION_c0000005_memory_corruption!Unknown
ANALYSIS_SOURCE: UM
FAILURE_ID_HASH_STRING: um:code_corruption_c0000005_memory_corruption!unknown
FAILURE_ID_HASH: {52b16108-a3a5-b115-868e-9fc9ce8e1ee0}
Followup: memory_corruption
---------
Can someone help to understand the cause of such crashes? If i try to check such dumps in DebugDiag , it shows the recursive call stack ...But what is the actual cause?
So I have a print server running Windows Server 2008 64 bit. It server up crystal reports to a variety of printers, some old, some new. That means there's a few different drivers on there. Recently we started having issues where the splWOW64 process will hang and all printing will back up. If we kill that process the queue prints normally. Looking at the what appears to be the hung print job every time we can see what printer and what report were printing, however it's never the same report or printer. We have full dumps of the splwow64 process and were told that the HP universal print driver PCL5 was causing the issue. It had been working for most of our printers for years before with no problems. So we removed that driving and started using individual drivers for each model of printer, all PCL6 if we could find them on the microsoft driver database. None of this has worked to fix the issue. It still happens 2-3 times a day depending on how busy it is. I've never used windbg to debug anything, I have below the results of !analyze -v -hang for a recent dump. It's gibberish to me at the moment. Maybe someone out there can see something obviously wrong?
FAULTING_IP:
+0
00000000`00000000 ?? ???
EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 0000000000000000
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 0
CONTEXT: 0000000000000000 -- (.cxr 0x0;r)
rax=0000000000000000 rbx=0000000000000000 rcx=00000000004486f8
rdx=00000000ffffffff rsi=00000000ffffffff rdi=0000000000000088
rip=0000000076d812fa rsp=000000000028f708 rbp=0000000000000001
r8=000000000028f7d8 r9=0000000000000001 r10=0000000000000000
r11=0000000000000202 r12=0000000000000000 r13=00000000ff963440
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
ntdll!NtWaitForSingleObject+0xa:
00000000`76d812fa c3 ret
FAULTING_THREAD: 0000000000000000
BUGCHECK_STR: HANG
DEFAULT_BUCKET_ID: APPLICATION_HANG
PROCESS_NAME: splwow64.exe
ERROR_CODE: (NTSTATUS) 0xcfffffff - <Unable to get error code text>
EXCEPTION_CODE: (NTSTATUS) 0xcfffffff - <Unable to get error code text>
NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS: 0
APP: splwow64.exe
ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) amd64fre
DERIVED_WAIT_CHAIN:
Dl Eid Cid WaitType
-- --- ------- --------------------------
0 b68.19bc Unknown
WAIT_CHAIN_COMMAND: ~0s;k;;
BLOCKING_THREAD: 00000000000019bc
PRIMARY_PROBLEM_CLASS: APPLICATION_HANG
LAST_CONTROL_TRANSFER: from 000007fefcfa10dc to 0000000076d812fa
STACK_TEXT:
00000000`0028f708 000007fe`fcfa10dc : 00000000`0044d000 00000000`00400000 00000000`0044cff0 00000000`76d840fd : ntdll!NtWaitForSingleObject+0xa
00000000`0028f710 000007fe`fd2ed95d : 00000000`004485f0 00000000`0000000a 00000000`00000000 00000000`00000088 : KERNELBASE!WaitForSingleObjectEx+0x79
00000000`0028f7b0 000007fe`fd36f42c : 00000000`00000000 00000000`00000000 00000000`004485f0 000007fe`fd2ff74e : rpcrt4!EVENT::Wait+0xd
00000000`0028f7e0 000007fe`fd33a879 : 00000000`004485f0 00000000`004485f0 00000000`00000000 00000000`00000001 : rpcrt4!RPC_SERVER::WaitForStopServerListening+0x1c
00000000`0028f810 000007fe`fd2ffa49 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000001 : rpcrt4!Invoke+0x13e46
00000000`0028f850 00000000`ff966b98 : 00000000`00000000 00000000`0000000a 00000000`0000000a 00000000`000004d2 : rpcrt4!RpcServerListen+0x49
00000000`0028f880 00000000`ff9671f1 : 00000000`00000000 00000000`0028fa20 00000000`00187c90 00000000`00003000 : splwow64!TLoad64BitDllsMgr::StartLdrRPCServer+0x19c
00000000`0028f9d0 00000000`ff967fb2 : 00000000`00187c90 00000000`00003000 00000000`00001a20 00000000`00003000 : splwow64!TLoad64BitDllsMgr::Run+0x4d
00000000`0028fa10 00000000`ff96d095 : 00000000`00000000 00000000`00000000 00000000`00187d20 00000000`00000000 : splwow64!wmain+0x1ae
00000000`0028fa50 00000000`76b2652d : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : splwow64!ConvertStringSecurityDescriptorToSecurityDescriptorW+0x19b
00000000`0028fa90 00000000`76d5c541 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd
00000000`0028fac0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d
FOLLOWUP_IP:
splwow64!TLoad64BitDllsMgr::StartLdrRPCServer+19c
00000000`ff966b98 8bd8 mov ebx,eax
SYMBOL_STACK_INDEX: 6
SYMBOL_NAME: splwow64!TLoad64BitDllsMgr::StartLdrRPCServer+19c
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: splwow64
IMAGE_NAME: splwow64.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 4f35fbfe
STACK_COMMAND: ~0s ; kb
BUCKET_ID: X64_HANG_splwow64!TLoad64BitDllsMgr::StartLdrRPCServer+19c
FAILURE_BUCKET_ID: APPLICATION_HANG_cfffffff_splwow64.exe!TLoad64BitDllsMgr::StartLdrRPCServer
ANALYSIS_SOURCE: UM
FAILURE_ID_HASH_STRING: um:application_hang_cfffffff_splwow64.exe!tload64bitdllsmgr::startldrrpcserver
FAILURE_ID_HASH: {369fae16-3854-e2c0-c756-fdab044a0958}
Followup: MachineOwner
You should make a kernel dump ( see: http://support.microsoft.com/kb/244139 )
Then you should do:
search your process !process 0 0 splwow64
switch to the found process
.process /p addr
list all thread for found process !process addr 17
find your thread
find ALPC handle in the stack and find a kernel object: !handle handle
print ALPC port object !alpc ob_addr
find a print corresponding server port
If you have done these step you must know a RPC server process which is hang your RPC request
Recently I have lost some of my debug functionality in Delphi 2007.
Specifically, the Watch List Window is completely disable as are all but a
few of the Watch List's popup menu items. The only menu items that are
enabled are
Add Group...
Show Column Headers
Stay on Top
Dockable
This is the case in the ide and the program running or not running
Breakpoints work as does tooltip expressions at breakpoint.
In Tools | Options , Code completion, Error Insight, Block Completion and
Code Template Completion are unchecked, all other options are checked.
In Tools | Options, Debugger Options are set Integrated Debugging and
Automatically close files implicitly...' checked , all others unchecked.
In Project | Options (Compiler), Optimization unchecked All Debugging
section items checked with exception of 'definitions only'
Conditional Defines are DEBUG;madExcept
When a breakpoint is hit, the Watch List windows shows 'Evaluating...' for
each Watch Name. BTW, the watch names were entered some time ago when all
debugging features were working.
After a period of attempted debugging while at a breakpoint (stopped), the
Run button on toolbar becomes disabled and I have to click 'Run | Program
Reset' on the menu at which time madExcept
throws the following exception from the IDE:
date/time : 2014-09-28, 09:08:17, 855ms
computer name : JOHNTAYLOR-LAP
user name : JT <admin>
registered owner : Microsoft / Microsoft
operating system : Windows 7 x64 build 7600
system language : English
system up time : 10 days 22 hours
program up time : 3 days
processors : 8x Intel(R) Core(TM) i7 CPU Q 840 # 1.87GHz
physical memory : 7944/16308 MB (free/total)
free disk space : (C:) 83.99 GB
display mode : 1024x768, 32 bit
process id : $2994
allocated memory : 354.77 MB
command line : "C:\CodeGear RAD Studio\CodeGear\RAD Studio\5.0\bin\bds.exe" -np
executable : bds.exe
current module : madExcept_.bpl
exec. date/time : 2007-12-11 15:04
version : 11.0.2902.10471
compiled with : Delphi 2006/07
madExcept version : 4.0.6
callstack crc : $f8d6ff12, $83616f26, $cd9b05a3
exception number : 1
exception class : EListError
exception message : List index out of bounds (0).
main thread ($325c):
20032558 +03c rtl100.bpl Classes 3525 +3 TInterfaceList.Put
2087a8f4 +008 dbkdebugide100.bpl Debug 6414 +1 TThread.RemoveNotifier
20aa3b13 +043 coreide100.bpl WatchWin 1543 +1 TWatchWindow.EvaluteComplete
20878cf9 +0fd dbkdebugide100.bpl Debug 5564 +12 TThread.EvalComplete
20877660 +02c dbkdebugide100.bpl Debug 4871 +2 TDbkApiEvent.Send
208784c8 +024 dbkdebugide100.bpl Debug 5300 +2 TDebugKernel.apiComplete
2013a81a +012 vcl100.bpl Controls 4039 +1 TControl.ScreenToClient
209b6b21 +065 coreide100.bpl EditorControl 6744 +3 TCustomEditControl.WMNCHitTest
7759e74d +078 ntdll.dll RtlAnsiStringToUnicodeString
76977b0a +016 USER32.dll CallWindowProcA
20885499 +039 dbkdebugide100.bpl Debug 11455 +3 TDebugger.DBKWndProc
20040e4c +014 rtl100.bpl Classes 11583 +8 StdWndProc
7696810d +00a USER32.dll DispatchMessageA
Can anyone help me get this straightened out ? This started suddenly about
a month ago and not pursuant to any new component installation that I am
aware of.
I had the same problem in BDS2006. And I found a very simple solution that worked for me. Open your project desktop-file (.dsk). Go to the watches section. I just removed some unwanted watches (don't forget to adjust the count), started Delphi again and my watches and menu-items were enabled.
I've just stumbled across this and I'm a bit puzzled.
I have an out-of-the-box VS 2010 F# project, with all default settings, targeting .NET 4.0.
The F# code is like this:
let test(a:int, b:int, c:int) = min a (min b c)
When I compile it for release, the generated IL contains some strange NOP
instructions scattered around. Like this:
The generated IL for this (with all default settings):
.method public static int32 test(int32 a,
int32 b,
int32 c) cil managed
{
// Code size 20 (0x14)
.maxstack 4
.locals init ([0] int32 V_0)
// HERE
IL_0000: nop
IL_0001: ldarg.1
IL_0002: ldarg.2
IL_0003: bge.s IL_0009
IL_0005: ldarg.1
// HERE
IL_0006: nop
IL_0007: br.s IL_000b
IL_0009: ldarg.2
// HERE
IL_000a: nop
IL_000b: stloc.0
IL_000c: ldarg.0
IL_000d: ldloc.0
IL_000e: bge.s IL_0012
IL_0010: ldarg.0
IL_0011: ret
IL_0012: ldloc.0
IL_0013: ret
} // end of method Module1::test
My .fsproj project configuration is:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<Tailcalls>true</Tailcalls>
<OutputPath>bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<WarningLevel>3</WarningLevel>
<DocumentationFile>bin\Release\TestFsIL.XML</DocumentationFile>
</PropertyGroup>
Now, if I comment out line <DebugType>pdbonly</DebugType>, the NOP instructions
disappear. But of course so does the PDB file!
.method public static int32 test(int32 a,
int32 b,
int32 c) cil managed
{
// Code size 17 (0x11)
.maxstack 4
.locals init (int32 V_0)
IL_0000: ldarg.1
IL_0001: ldarg.2
IL_0002: bge.s IL_0007
IL_0004: ldarg.1
IL_0005: br.s IL_0008
IL_0007: ldarg.2
IL_0008: stloc.0
IL_0009: ldarg.0
IL_000a: ldloc.0
IL_000b: bge.s IL_000f
IL_000d: ldarg.0
IL_000e: ret
IL_000f: ldloc.0
IL_0010: ret
} // end of method Module1::test
There is also a subtle different in the .locals line:
.locals init ([0] int32 V_0)
vs
.locals init (int32 V_0)
When I tried C# compiler, it generates NOP instructions only in the
debug builds, but these seem to go away in release builds, even when
PDB files are included using <DebugType>pdbonly</DebugType>.
Questions:
Why are NOP instructions generated in F# in release build when PDB files are included, when C# seems to be able to avoid this.
Is there any way to get rid of those NOP, but still have the PDB files?
PS. There are related questions on SO here
and here,
but all the answers there say
you are compiling in debug mode, if you compile in release mode, the NOP goes away
which contradicts my experience with F# compiler as demonstrated.
I don't exactly know how this works internally in the F# compiler (somebody from the F# team may have a better answer), but my guess is that generating nop instructions is just a fairly easy way to generate locations that can be referred to from the pdb file.
The pdb file needs to specify some IL range for expression in the code where you can place a breakpoint - and this is the case in both Debug and Release mode. This means that if you place a breakpoint somewhere, there needs to be a corresponding location in the IL. However, if there is no actual instruction, corresponding to the source code location, the compiler needs to insert something - so it adds nop.
In Release mode, the F# compiler does more optimizations, but if you want pdb files, it still needs to provide location for all source code locations. This might not be needed in C#, because C# maps more closely to the source IL, but it might be harder to avoid this in F#.
I getting a kernel crash as below. Here I can observe large memory is present in unevictablle page.
I wish to know when exactly memory is added to unevictable page list.
Also, from the below message I can understand only 1724kB is available in the system.
is it correct?
kswapd0: page allocation failure. order:0, mode:0xd0
[<c002aed4>] (unwind_backtrace+0x0/0xdc) from [<c006d5b0>] (__alloc_pages_nodemask+0x490/0x4ec)
[<c006d5b0>] (__alloc_pages_nodemask+0x490/0x4ec) from [<c008416c>] (cache_alloc_refill+0x260/0x4f4)
[<c008416c>] (cache_alloc_refill+0x260/0x4f4) from [<c0084498>] (__kmalloc+0x98/0xd8)
[<c0084498>] (__kmalloc+0x98/0xd8) from [<c01f73d8>] (__alloc_skb+0x44/0x124)
[<c01f73d8>] (__alloc_skb+0x44/0x124) from [<c01f7cac>] (skb_copy+0x2c/0xa0)
Exception stack(0xc4ecbdf0 to 0xc4ecbe38)
bde0: 00000000 00000064 c0347718 00000000
be00: 00000001 00000000 c0347718 c0347718 c4ecbf54 00000000 00000000 000000fd
be20: c4ecbf00 c4ecbe38 c00724b4 c00724c4 80000013 ffffffff
[<c0024b18>] (__irq_svc+0x38/0xc0) from [<c00724c4>] (shrink_zone+0x88/0x70c)
[<c00724c4>] (shrink_zone+0x88/0x70c) from [<c0072ff4>] (kswapd+0x34c/0x4d8)
[<c0072ff4>] (kswapd+0x34c/0x4d8) from [<c004dcec>] (kthread+0x7c/0x84)
[<c004dcec>] (kthread+0x7c/0x84) from [<c0025ed0>] (kernel_thread_exit+0x0/0x8)
Mem-info:
Normal per-cpu:
CPU 0: hi: 42, btch: 7 usd: 36
Active_anon:124 active_file:0 inactive_anon:129
inactive_file:0 unevictable:8111 dirty:0 writeback:0 unstable:0
free:431 slab:19526 mapped:408 pagetables:53 bounce:0
Normal free:1724kB min:1396kB low:1744kB high:2092kB active_anon:496kB inactive_anon:516kB active_file:0kB inactive_file:0kB unevictable:32444kB present:121920kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0
Normal: 103*4kB 34*8kB 3*16kB 3*32kB 2*64kB 0*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB = 1724kB
8114 total pagecache pages
30720 pages of RAM
547 free pages
1204 reserved pages
19526 slab pages
1662 pages shared
0 pages swap cached
Unevictable pages are simply pages that can't be paged out for a variety of reasons. It might mean that the page belongs to a ramdisk, was protected by a call to mlock(), shared and locked, or any other circumstances where the kernel was told 'don't touch'. This is managed by the kernel's LRU framework.
Can you provide some more context into the crash?