VirtualBox

Ticket #10866 (new defect)

Opened 20 months ago

Last modified 20 months ago

VBoxHeadless crashed in _malloc_unlocked

Reported by: arb Owned by:
Priority: critical Component: other
Version: VirtualBox 4.1.18 Keywords:
Cc: Guest type: other
Host type: Solaris

Description (last modified by frank) (diff)

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.

Attachments

VBox.log.bz2 Download (89.4 KB) - added by arb 20 months ago.

Change History

comment:1 Changed 20 months ago by sunlover

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

Changed 20 months ago by arb

comment:2 Changed 20 months ago by arb

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

comment:3 Changed 20 months ago by frank

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

comment:4 Changed 20 months ago by frank

  • Description modified (diff)

comment:5 Changed 20 months ago by 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).

comment:6 Changed 20 months ago by frank

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.

comment:7 Changed 20 months ago by 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)?

comment:8 Changed 20 months ago by frank

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.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use