I'm seeing an AV in python allocation logic when running my scripts. This only happens when using embedded python. It does not reproduce when using installed python. This is on Windows x86-64, I'm running Windows 10. I've seen this on 3.6.5 and 3.7.1.

Here's the 3.7.1 stack on failure:

0:004> kpn
 # Child-SP          RetAddr           Call Site
00 000000d1`7439d650 00007ff8`e8303db6 python37!pymalloc_alloc(void ** ptr_p = 0x000000d1`7439d6c0, unsigned int64 nbytes = <Value unavailable error>)+0x4b [c:\_work\5\s\objects\obmalloc.c @ 1398] 
01 000000d1`7439d680 00007ff8`e82fb064 python37!_PyObject_Malloc(void * ctx = 0x00000000`00000000, unsigned int64 nbytes = 0x1c)+0x16 [c:\_work\5\s\objects\obmalloc.c @ 1555] 
02 (Inline Function) --------`-------- python37!PyObject_Malloc+0x1c [c:\_work\5\s\objects\obmalloc.c @ 616] 
03 000000d1`7439d6b0 00007ff8`e82fb18c python37!_PyLong_New(int64 size = 0n1)+0x40 [c:\_work\5\s\objects\longobject.c @ 210] 
04 000000d1`7439d6e0 00007ff8`e83cbf28 python37!PyLong_FromLongLong(int64 ival = <Value unavailable error>)+0x4c [c:\_work\5\s\objects\longobject.c @ 1102] 
05 (Inline Function) --------`-------- python37!_PyLong_FromTime_t+0xc [c:\_work\5\s\python\pytime.c @ 88] 
06 000000d1`7439d710 00007ff8`e83cb86e python37!tmtotuple(struct tm * p = 0x000000d1`7439d768, char * zone = 0x000000d1`7439d7c0 "Pacific Standard Time", int64 gmtoff = 0n-28800)+0xe0 [c:\_work\5\s\modules\timemodule.c @ 426] 
07 000000d1`7439d740 00007ff8`e8307e18 python37!time_localtime(struct _object * self = 0x0000029f`3753bbe0, struct _object * args = <Value unavailable error>)+0x96 [c:\_work\5\s\modules\timemodule.c @ 521] 
08 000000d1`7439d850 00007ff8`e8308737 python37!_PyMethodDef_RawFastCallKeywords(struct PyMethodDef * method = 0x00000000`00000000, struct _object * self = 0x0000029f`371b7778, struct _object ** args = 0x0000029f`3754b3c8, int64 nargs = 0n1, struct _object * kwnames = 0x00000000`00000000)+0x3a8 [c:\_work\5\s\objects\call.c @ 694] 
09 (Inline Function) --------`-------- python37!_PyCFunction_FastCallKeywords+0x22 [c:\_work\5\s\objects\call.c @ 730] 
0a 000000d1`7439d8d0 00007ff8`e83091d3 python37!call_function(struct _object *** pp_stack = 0x000000d1`7439da28, int64 oparg = <Value unavailable error>, struct _object * kwnames = 0x00000000`00000000)+0x3a7 [c:\_work\5\s\python\ceval.c @ 4554] 
0b 000000d1`7439d990 00007ff8`e82f1390 python37!_PyEval_EvalFrameDefault(struct _frame * f = 0x0000029f`3754b220, int throwflag = 0n928230480)+0x913 [c:\_work\5\s\python\ceval.c @ 3095] 
0c (Inline Function) --------`-------- python37!PyEval_EvalFrameEx+0x17 [c:\_work\5\s\python\ceval.c @ 547] 
0d 000000d1`7439dad0 00007ff8`e83086a2 python37!_PyEval_EvalCodeWithName(struct _object * _co = 0x0000029f`37415a50, struct _object * globals = <Value unavailable error>, struct _object * locals = <Value unavailable error>, struct _object ** args = 0xffffffff`ffff2a88, int64 argcount = 0n3, struct _object ** kwnames = 0x00000000`00000000, struct _object ** kwargs = 0x0000029f`3753de28, int64 kwcount = 0n0, int kwstep = 0n1, struct _object ** defs = 0x0000029f`3743fe60, int64 defcount = 0n1, struct _object * kwdefs = 0x00000000`00000000, struct _object * closure = 0x00000000`00000000, struct _object * name = 0x0000029f`3744f470, struct _object * qualname = 0x0000029f`37441930)+0x1a0 [c:\_work\5\s\python\ceval.c @ 3930] 
0e (Inline Function) --------`-------- python37!_PyFunction_FastCallKeywords+0x274 [c:\_work\5\s\objects\call.c @ 433] 
0f 000000d1`7439db80 00007ff8`e8308d29 python37!call_function(struct _object *** pp_stack = 0x000000d1`7439dcd8, int64 oparg = <Value unavailable error>, struct _object * kwnames = 0x00000000`00000000)+0x312 [c:\_work\5\s\python\ceval.c @ 4607] 
....

Actually, I have now seen this in full installed python. I have updated the title.

Try to reproduce your bug using PYTHONMALLOC=debug environment variable:
https://pythondev.readthedocs.io/debug_tools.html#memory-debugger

On Python 3.7, you can use "py -3.7 -X dev program.py" (-X dev option) to enable PYTHONMALLOC=debug.

I have reproduced this with both PYTHONMALLOC=debug and "py -3.7 -x dev <my program>", but it did not print out any allocation debug info. When using this option, it does take many more attempts to hit the issue than if running without debugging turned on.

Is there some other useful info I can gather?

Correction to my previous post. I did use capital X, ie '-X dev'.

This reproduces stably for me when running unit tests in Python.NET project at commit 5e276d9.

In my case it always happens in pymalloc_alloc when size == 5, e.g. when accessing usedpools[10].
Specifically freeblock pointer in usedpools[10] is waaaay off (essentially, seemingly random number looking like 0xXXXXX000) where it is supposed to be (e.g. very far from usedpools[10]). Surprisingly, all the other fields in usedpool[10] seem to have normal values.

I could not find any place in obmalloc.c where this value would be set, so it seems to be a memory corruption caused by something else.

A bit more information: pool->freeblock for the broken pool looks like this:
0xXYZ?????
while pool itself looks like this:
0x??XYZ000