Opened 13 years ago
Closed 10 years ago
#10866 closed defect (obsolete)
VBoxHeadless crashed in _malloc_unlocked
| Reported by: | arb | Owned by: | |
|---|---|---|---|
| Component: | other | Version: | VirtualBox 4.1.18 |
| Keywords: | Cc: | ||
| Guest type: | other | Host type: | Solaris |
Description (last modified by )
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 (1)
Change History (10)
comment:1 by , 13 years ago
by , 13 years ago
| Attachment: | VBox.log.bz2 added |
|---|
comment:3 by , 13 years ago
Does it change anything if you enable the host I/O cache for the storage controller?
comment:4 by , 13 years ago
| Description: | modified (diff) |
|---|
comment:5 by , 13 years ago
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 by , 13 years ago
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 by , 13 years ago
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 by , 13 years ago
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.
comment:9 by , 10 years ago
| Resolution: | → obsolete |
|---|---|
| Status: | new → closed |
Please attach VBox.log of the session, where the crash happened.