VBoxHeadless crashed in _malloc_unlocked

[arb]

VBoxHeadless crashed and dumped core.

Stack:

current thread: t@11
  [1] _malloc_unlocked(0x0, 0x0, 0x28289a0, 0xe0, 0x5, 0x5), at 0xfffffd7fff0a8f6c 
  [2] malloc(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff0a8e8d 
=>[3] operator new(sz = 152U), line 48 in "new_op.cc"
  [4] hgcmMessageAllocSvc(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffe4004db 
  [5] HGCMThread::MsgAlloc(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffe3ff77c 
  [6] hgcmMsgAlloc(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffe3ffd78 
  [7] HGCMService::GuestCall(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffe40194b 
  [8] HGCMGuestCall(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffe40261a 
  [9] iface_hgcmCall(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffe3cd709 
  [10] vmmdevHGCMCall(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffa6aae26 
  [11] vmmdevRequestHandler(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffa6a738d 
  [12] IOMIOPortWrite(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffe118c93 
  [13] HWACCMR3RestartPendingIOInstr(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffe108577 
  [14] emR3HwaccmHandleRC(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffe16a9aa 
  [15] emR3HwAccExecute(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffe16ac6c 
  [16] EMR3ExecuteVM(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffe168550 
  [17] vmR3EmulationThreadWithId(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffe0f83ef 
  [18] rtThreadMain(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffeb9fc1c 
  [19] rtThreadNativeMain(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7ffebecd11 
  [20] _thr_setup(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff10bfbb 
  [21] _lwp_start(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff10c1e0 

I can't attach the core file, it's hundreds of MB.

[sunlover]

Please attach VBox.log of the session, where the crash happened.

[arb]

Had to compress it, sorry, it was too large uncompressed.

[Frank Mehnert]

Does it change anything if you enable the host I/O cache for the storage controller?

[arb]

Everything I have read suggests that I should NOT be using the host I/O cache (timeouts, corruption, and wasting precious host memory) so I am very reluctant to enable it (the VMs are all extremely intensive users of I/O).

[Frank Mehnert]

It might help anyway to narrow-down your problem. Your log file contains a lot of warnings that I/O requests took a long time. If you enable the host I/O cache then another code path is taken. If you cannot reproduce this crash with the host I/O cache enabled then this would be a hint. Apart from this, don't expect miracles. When running several guests in parallel where each guest induces a big host I/O load, the limiting factor will be still your hard disk. And a guest is confused if an I/O requests takes too long.

[arb]

I can enable the host I/O cache but I can't provoke a crash. Given how many other things might change before it happens again it would be difficult to say whether or not the cache change is significant. Maybe you can debug it from the backtrace (maybe the core also)?

[Frank Mehnert]

No, unfortunately I cannot debug this from the backtrace. The reason is that this is 99% some kind of memory corruption, otherwise malloc() would not crash.