VirtualBox

Ticket #487 (closed defect: fixed)

Opened 7 years ago

Last modified 4 years ago

VBox crashes often

Reported by: moonlight Owned by:
Priority: critical Component: other
Version: VirtualBox 1.4.0 Keywords:
Cc: Guest type: other
Host type: other

Description

Host: Ubuntu 7.04, VRAM: 16Mb Guest: Windows 2003 server

VBox works at most 1.5 hours then crashes. (Or may work 10 minutes before crash)

Attachments

VBox.log Download (23.7 KB) - added by moonlight 7 years ago.
VBox.2.log Download (24.5 KB) - added by msundman 7 years ago.
The log that was created in the same session that the core was dumped.

Change History

Changed 7 years ago by moonlight

comment:1 Changed 7 years ago by sandervl73

More information is needed. VBox crashes or the guest? Do you have a call trace?

comment:2 Changed 7 years ago by moonlight

VBox crashes or the guest?

VBox, surely. Not guest (guest may crash, but there is no way to find whether it happened or not due to crash of VBox)

Do you have a call trace?

No, how can I get it?

comment:3 Changed 7 years ago by klaus

The easiest way to get a call trace is enabling core dumps (with "ulimit -c unlimited"), and start VirtualBox from exactly the shell where you enabled core dumps. Make sure no VirtualBox-related processes are running initially.

After it crashes, you should get a file named core (with or without a suffix indicating the process ID of the crashed process). It could be in the current directory or somewhere in the ~/.VirtualBox direcory tree.

Once you located this file, you need to find out what program crashed - by running "file core". To get the call trace, run "gdb program core", and issue the command "bt" at the debugger prompt. After attaching the backtrace to this ticket you can exit the debugger with "quit".

comment:4 Changed 7 years ago by moonlight

Core dump is here  ftp://dian.dyndns.biz/tmp/VBox_dumps/virtualbox_1.4.1-22865_Ubuntu_feisty_i386/vm_runtime_crash.tar.bz2 Note it's large enough, about 70 Mb. It's also will not be in public access for a long time due to security considerations

comment:5 Changed 7 years ago by frank

Please could you try VirtualBox 1.5.0?

comment:6 Changed 7 years ago by nosilver4u

I just upgraded to 1.5, and I've only ever really used it for a Windows guest (running on Ubuntu 7.04 host). I have no problems with Windows, but guests with both Ubuntu 7.04 and 7.10 (gutsy) crash regularly. It may just be a coincidence, but it seems to always be when I'm running apt in the guest.

comment:7 Changed 7 years ago by frank

Please could you provide a core dump? Execute

ulimit -c unlimied

before starting VirtualBox. If your bash complains about permissions, make sure that your ~/.bashrc, ~/.bash_profile, ~/.profile do not contain any 'ulimit -c 0' line.

comment:8 Changed 7 years ago by frank

Typo, use pls use unlimited, not unlimied.

comment:9 Changed 7 years ago by msundman

you need to find out what program crashed - by running "file core".

$ file core
core: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), SVR4-style
$

Uhh?

comment:10 follow-up: ↓ 11 Changed 7 years ago by frank

gdb -c core

should tell you, which application crashed.

comment:11 in reply to: ↑ 10 Changed 7 years ago by msundman

gdb -c core:

GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
Core was generated by `/usr/lib/virtualbox/VirtualBox -comment Win2k -startvm edadd986-9c53-4a56-439d-'.
Program terminated with signal 6, Aborted.
#0  0xffffe410 in __kernel_vsyscall ()
(gdb) 

gdb /usr/lib/virtualbox/VirtualBox core:

[...]
(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb5883df0 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb5885641 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0xb58b99bb in ?? () from /lib/tls/i686/cmov/libc.so.6
#4  0x00000029 in ?? ()
#5  0xb3cfe820 in ?? ()
#6  0x00000400 in ?? ()
#7  0xb5ea2f95 in ldub_code_raw () from /usr/lib/VBoxREM.so
#8  0xbfd8591b in ?? ()
#9  0x0000001e in ?? ()
#10 0xb59807c1 in ?? () from /lib/tls/i686/cmov/libc.so.6
#11 0x00000002 in ?? ()
#12 0xb59808c4 in ?? () from /lib/tls/i686/cmov/libc.so.6
#13 0x00000022 in ?? ()
#14 0xb59807c5 in ?? () from /lib/tls/i686/cmov/libc.so.6
#15 0x00000004 in ?? ()
#16 0xb3cfedd7 in ?? ()
#17 0x00000008 in ?? ()
#18 0xb59807cb in ?? () from /lib/tls/i686/cmov/libc.so.6
#19 0x00000005 in ?? ()
#20 0xb01eaffc in ?? ()
#21 0x850f0011 in ?? ()
#22 0x00000000 in ?? ()
(gdb) 

Changed 7 years ago by msundman

The log that was created in the same session that the core was dumped.

comment:12 Changed 7 years ago by msundman

Btw, the guest OS in this case was Windows 2000, not Windows 2003 Server.

comment:13 follow-up: ↓ 14 Changed 7 years ago by frank

Please could you attach the core? If so, please pack it using bzip2 or something.

comment:14 in reply to: ↑ 13 Changed 7 years ago by msundman

Replying to frank:

Please could you attach the core? If so, please pack it using bzip2 or something.

No, I can't, because the maximum attachment size here is 400000 bytes and the 7z-compressed core is 40974445 bytes.

comment:15 follow-up: ↓ 16 Changed 7 years ago by frank

I see. Can you put it on a website where I can fetch it? If not, could you split the file in parts which are smaller than 4MB (e.g. man split)?

Thanks for your help.

comment:16 in reply to: ↑ 15 Changed 7 years ago by msundman

Replying to frank:

I see. Can you put it on a website where I can fetch it? If not, could you split the file in parts which are smaller than 4MB (e.g. man split)?

I'm not going to upload 103 pieces. I managed to put it online, but it's exceeding my quota so I'll have to remove it soon:  http://www.abo.fi/~masundma/tmp/crash2.7z

comment:17 Changed 7 years ago by frank

Have it.

comment:18 Changed 7 years ago by frank

  • Status changed from new to closed
  • Resolution set to fixed

It is very likely that we fixed that problem in 1.5.2. I will close this bug, please reopen if still relevant.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use