https://bugs.winehq.org/show_bug.cgi?id=55761
--- Comment #6 from Bernhard Übelacker bernhardu@mailbox.org --- Short before the crash following lines are printed:
Call ucrtbase.malloc(7f630000e8c0) ret=7fffec5b3122 err:virtual:map_view anon mmap error Cannot allocate memory, size 0x7f6300020000, unix_prot 0 err:virtual:allocate_virtual_memory out of memory for allocation, base (nil) size 7f6300010000 Ret ucrtbase.malloc() retval=00000000 ret=7fffec5b3122 trace:seh:dispatch_exception code=c0000005 flags=0 addr=00007FFFEC5B0A23 ip=7fffec5b0a23
I tried to compare that size of 7f630000e8c0 with a working run and found there it just allocating 0xe8c0 bytes.
Further following that 7f630000e8c0 back and found following instruction clearing just the lower 32 bit of the value.
Old value = (void *) 0x7f637a624e70 New value = (void *) 0x7f6300000000 0x0000000000a60807 in TMethodImplementationIntercept () from plsqldev.exe 1: x/i $pc => 0xa60807 <TMethodImplementationIntercept+5569847>: movl $0x0,0x30(%rsp)
Therefore it looks like this is really a bug of plsqldev.exe, but it is not showing up in windows because there the upper 32 bit of the incorrectly cleared memory are always zero.
Something similar seems to be observed in #55908.