On Sat, Jan 9, 2016 at 10:02 PM, <sergey-v@mail.ru> wrote:
> Last time i've capture the call stack of the thread consuming the CPU (via
> https://technet.microsoft.com/en-us/sysinternals/processexplorer):
>
> ntoskrnl.exe!memset+0x61a
> ntoskrnl.exe!KeWaitForMultipleObjects+0xd52
> ntoskrnl.exe!KeWaitForMutexObject+0x19f
> ntoskrnl.exe!_misaligned_access+0xba4
> ntoskrnl.exe!_misaligned_access+0x1821
> ntoskrnl.exe!KiCheckForKernelApcDelivery+0x25
> ntoskrnl.exe!MmProbeAndLockPages+0xbc6
> afd.sys+0x460f3
> afd.sys+0x45963
> ntoskrnl.exe!NtMapViewOfSection+0x15b7
> ntoskrnl.exe!NtDeviceIoControlFile+0x56
> ntoskrnl.exe!KeSynchronizeExecution+0x3a23
> ntdll.dll!ZwDeviceIoControlFile+0xa
> mswsock.dll+0x174d
> WS2_32.dll!WSARecv+0x169
> postgres.exe!pgwin32_recv+0x79
> plugin_debugger.dll!BreakpointFreeSession+0x3f1
> plugin_debugger.dll!pg_finfo_pldbg_set_global_breakpoint+0xd6e]
Looking at this stack, this bit is not from Postgres core, but from
pgadmin. My first thought is that there is some logic that has been
fixed in 29692bd that this plugin does not like or does not expect.
--
Michael