Host+Del crashes

[rsparapa@…]

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.

[rsparapa@…]

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

[Frank Mehnert]

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?

[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.

[Ramshankar Venkataraman]

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

[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

[rsparapa@…]

Can you give me an update?

[Michael Thayer]

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.

[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

[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

?!?

[Ramshankar Venkataraman]

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

[rsparapa@…]

Still broken in 3.1.0

[Frank Mehnert]

... and still no core dump ...

[rsparapa@…]

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

[Frank Mehnert]

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

[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.

[Ramshankar Venkataraman]

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".

[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.

[rsparapa@…]

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

[rsparapa@…]

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

[Ramshankar Venkataraman]

Thanks a lot for updating the defect.