VirtualBox

Ticket #5050 (closed defect: fixed)

Opened 5 years ago

Last modified 4 years ago

Host+Del crashes

Reported by: rsparapa@… Owned by:
Priority: major Component: other
Version: VirtualBox 3.0.2 Keywords:
Cc: Guest type: Windows
Host type: Solaris

Description

I have never been able to make Host+Del work for me. It always crashes VirtualBox. I suppose there is some reason why Control-Alt-Del does not work either.

Attachments

rsparapa-2009-09-23-08-21-29.log Download (35.1 KB) - added by rsparapa@… 5 years ago.
core Download (64 bytes) - added by rsparapa@… 4 years ago.

Change History

comment:1 Changed 5 years ago by rsparapa@…

Oops, I forgot to fill in Host/Guest. Host is Solaris 10 and Guest is Windows XP SP3.

comment:2 Changed 5 years ago by frank

  • Host type changed from other to Solaris
  • Guest type changed from other to Windows

Well, pressing Host+Del crashes your VM session? That's weird. The reason that Ctrl-Alt-Del is not allowed is that this does not work on Windows hosts (Windows does not pass this key combination to applications) so we decided to unify the handling on all hosts.

I assume your VM crashes as well when you select this key combination from the menu?

comment:3 Changed 5 years ago by rsparapa@…

No, when selecting from the menu, then it does not crash. So, fixing this would help (and allowing Control-Alt-Del on other hosts would seem to make sense too; we use VNC also and it would be nice to be consistent). Thanks.

comment:4 Changed 5 years ago by ramshankar

I'm not able to reproduce this, could you please attach a VBox.log where this happens?

Changed 5 years ago by rsparapa@…

comment:5 Changed 5 years ago by rsparapa@…

In the beginning of the output, I see:

Failed to recognize the keyboard mapping or to guess it based on the keyboard layout. It is very likely that some keys will not work correctly in the guest. If you would like to help us improve the product, please submit a bug report, giving us information about your keyboard type, its layout and other relevant information such as whether you are using a remote X server or something similar.

My keyboard type is a Sun Type 7 PC style  http://www.sun.com/desktop/products/peripherals/keyboard/

And we are using Sun Ray clients  http://www.sun.com/desktop/sun-ray-clients.jsp with Sun Ray Server Software 4.0: name of display: :3.0 version number: 11.0 vendor string: Sun Microsystems, Inc. vendor release number: 6620 maximum request size: 262140 bytes motion buffer size: 256 bitmap unit, bit order, padding: 32, LSBFirst, 32 image byte order: LSBFirst number of supported pixmap formats: 4 supported pixmap formats:

depth 1, bits_per_pixel 1, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32

keycode range: minimum 8, maximum 254 focus: window 0x780041, revert to Parent number of extensions: 30

AccessX Adobe-DPS-Extension DAMAGE DOUBLE-BUFFER DPMS DPSExtension Extended-Visual-Information LBX MIT-SCREEN-SAVER MIT-SHM MIT-SUNDRY-NONSTANDARD Multi-Buffering RECORD SECURITY SHAPE SUN_ALLPLANES SUN_DGA SUN_OVL SUN_SME SYNC SolarisIA TOG-CUP X-Resource XC-APPGROUP XC-MISC XEVIE XFIXES XInputDeviceEvents XInputExtension XTEST

default screen number: 0 number of screens: 1

screen #0:

dimensions: 3840x1200 pixels (1083x338 millimeters) resolution: 90x90 dots per inch depths (4): 1, 8, 24, 32 root window id: 0x30 depth of root window: 24 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x24 default number of colormap cells: 256 preallocated pixels: black 0, white 16777215 options: backing-store YES, save-unders YES largest cursor: 64x64 current input event mask: 0xfa6033

KeyPressMask KeyReleaseMask EnterWindowMask LeaveWindowMask ButtonMotionMask KeymapStateMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask PropertyChangeMask ColormapChangeMask

number of visuals: 2 default visual id: 0x21 visual:

visual id: 0x20 class: PseudoColor depth: 8 planes available colormap entries: 256 red, green, blue masks: 0x0, 0x0, 0x0 significant bits in color specification: 8 bits

visual:

visual id: 0x21 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff, 0xff00, 0xff0000 significant bits in color specification: 8 bits

comment:6 Changed 5 years ago by rsparapa@…

Can you give me an update?

comment:7 Changed 5 years ago by michael

Can you supply a  core dump for the crash? Please mention which version of VirtualBox it is against. That might help to understand what is going wrong.

comment:8 Changed 5 years ago by rsparapa@…

The bug still exists in 3.0.8. However, it doesn't crash VirtualBox. It crashes the VM. And, no core is produced:

% limit cputime unlimited filesize unlimited datasize unlimited stacksize 10MB coredumpsize unlimited descriptors 256 vmemorysize unlimited

% coreadm

global core file pattern: global core file content: default

init core file pattern: core init core file content: default

global core dumps: disabled

per-process core dumps: enabled

global setid core dumps: disabled

per-process setid core dumps: disabled

global core dump logging: disabled

comment:9 Changed 5 years ago by rsparapa@…

And, the kill -4 trick does not produce a core either:

rsparapa 21693 21630 0 16:07:47 ? 2:31 /opt/VirtualBox/amd64/VirtualBox --comment rsparapa --startvm 81da5d34-a2cd-457

kill -4 21693

?!?

comment:10 Changed 4 years ago by ramshankar

You need to enable setuid coredumps, check  http://www.virtualbox.org/wiki/Core_dump (How to provide core dump on Solaris)

comment:11 Changed 4 years ago by rsparapa@…

Still broken in 3.1.0

comment:12 Changed 4 years ago by frank

... and still no core dump ...

comment:13 Changed 4 years ago by rsparapa@…

As I said in my previous remarks, no core is produced.

comment:14 Changed 4 years ago by frank

Did you see the remark of Ramshankar? Did you check the link he posted?

comment:15 Changed 4 years ago by rsparapa@…

Yes I did. Unfortunately, VirtualBox does not produce core files. I'm not sure where the problem is since other apps do produce core files.

comment:16 Changed 4 years ago by ramshankar

Could you please then check "/var/adm/messages" for failure to dump the core file. If your coreadm is setup properly to dump setuid binary cores, a failure to dump should produce something like "address space is changing, cannot dump" or similar in the syslog.

Additionally just to be sure could you also paste output of "coreadm".

comment:17 Changed 4 years ago by rsparapa@…

Ah, sorry. I misunderstood. I didn't realize that setuid dumps were needed. The description that you posted was for OpenSolaris and Solaris doesn't work exactly the same way. So, I must have missed the setuid part. Anyways, the core is now attached.

Changed 4 years ago by rsparapa@…

  • attachment core Download added

comment:18 Changed 4 years ago by rsparapa@…

Oh, but now I see that WARNING: elfcore: core dump failed for process 1227; address space is changing!?!

comment:19 Changed 4 years ago by rsparapa@…

After upgrading to VB 3.2.6 and SRSS 4.2, I don't see this problem any more.

comment:20 Changed 4 years ago by ramshankar

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

Thanks a lot for updating the defect.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use