Thread: BUG #13858: Server with debugger installed consumes 100% of one CPU core

The following bug has been logged on the website:

Bug reference:      13858
Logged by:          Sergey
Email address:      sergey-v@mail.ru
PostgreSQL version: 9.5.0
Operating system:   Windows 7 x64
Description:

It happened few times today - after some period and I'm not sure which
particular my actions, one of the postgres.exe process starts eating 100% of
one CPU core.

I've found only way to fix that - kill that process, because normal control
functions do not work (i.e. stopping server from pgAdmin).

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
    plpgsql.dll!exec_get_datum_type_info+0xd65
    plpgsql.dll!exec_get_datum_type_info+0xcff
    plpgsql.dll!exec_get_datum_type_info+0x142a
    plpgsql.dll!exec_get_datum_type_info+0xe14
    plpgsql.dll!exec_get_datum_type_info+0xcff
    plpgsql.dll!exec_get_datum_type_info+0x142a
    plpgsql.dll!exec_get_datum_type_info+0xe14
    plpgsql.dll!exec_get_datum_type_info+0xbbb
    plpgsql.dll!plpgsql_exec_function+0x2e6
    plpgsql.dll!plpgsql_call_handler+0x11f
    postgres.exe!ExecProject+0x1ea8
    postgres.exe!ExecProject+0x1f60
    postgres.exe!ExecProject+0x47fa
    postgres.exe!ExecProject+0x166
    postgres.exe!ExecResult+0xb4
    postgres.exe!ExecProcNode+0x82
    postgres.exe!EvalPlanQualEnd+0x8cd
    postgres.exe!standard_ExecutorRun+0xa8
    postgres.exe!PortalRunFetch+0x64b
    postgres.exe!PortalRun+0x1c7
    postgres.exe!get_stats_option_name+0x2a19
    postgres.exe!PostgresMain+0x703
    postgres.exe!ShmemBackendArrayAllocation+0x2a6a
    postgres.exe!SubPostmasterMain+0x273
    postgres.exe!main+0x480
    postgres.exe!pgwin32_popen+0x130b
    kernel32.dll!BaseThreadInitThunk+0xd
    ntdll.dll!RtlUserThreadStart+0x21

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