VirtualBox

Ticket #11356 (closed defect: invalid)

Opened 9 years ago

Last modified 9 years ago

Guest Additions video module 4.2.6 and glibc 2.17, compatibility issue causes X to hang on start

Reported by: wideaperture Owned by:
Component: guest additions Version: VirtualBox 4.2.6
Keywords: Cc:
Guest type: other Host type: other

Description

System Information

I am running a 32-bit Arch Linux guest on an OS X 10.7.5 host using VirtualBox 4.2.6.

Issue

On my Arch Linux guest, updating glibc-2.16.0-5 and dependencies (binutils-2.23.1-1, gcc-4.7.2-2, gcc-libs-4.7.2-2) to glibc 2.17-1, binutils-2.23.1-2, gcc-4.7.2-3, and gcc-libs-4.7.2-3 from the Arch repository causes X to hang on start and prevents me from launching my gnome desktop.

Solutions Attempted

Actions that Temporarily Resolve the Problem

  • Downgrading glibc and its dependencies to the aforementioned version numbers temporarily resolves the problem.

Actions that Did Not Resolve the Problem

  • I tried updating glibc and dependencies on two Arch VMs, one running the version of Guest Additions 4.2.6 installed through the VirtualBox devices menu, and the second running the version of Guest Additions 4.2.6 installed from official Arch "community" repository. The problem occurs in both cases.
  • Other users  on the Arch bug tracker report that rebuilding Guest Additions after updating glibc does not resolve the problem.
  • Other users  on the Arch forums have tried downgrading to Guest Additions 4.2.4 and report that this does not resolve the problem.

Logs

I have posted  the output of my Xorg.0.log on pastie.org.

Other Reports of the Issue

  • I  reported this bug earlier on the Arch bug tracker, and other users have responded with their own reports. More information about my own system is also available there, including the versions of all packages related to X that I am running.

Change History

comment:1 Changed 9 years ago by wideaperture

A couple things:

  • While they're written out at the top of the ticket, I forgot to fill in the form fields asking for my host type and guest type (OS X 10.7.5 and Arch Linux, respectively). If a good Samaritan with ticket modify privileges happens along, I'd greatly appreciate it if s/he could add this information.
  • Over  on the Arch bug tracker, the glibc folks have laid the problem on VirtualBox, so some help on this problem from the VirtualBox community would be even more greatly appreciated at this point.
Last edited 9 years ago by wideaperture (previous) (diff)

comment:2 Changed 9 years ago by wideaperture

An Arch user  has located the glibc commit that is causing the Guest Additions video module to barf. This should be helpful in resolving the issue.

comment:3 Changed 9 years ago by frank

Thanks for this report. We are investigating but please keep in mind, that glibc 2.17 is even not released yet still brand-new and not yet used by major Linux distributions. Therefore this problem is lower-prior for us.

Last edited 9 years ago by frank (previous) (diff)

comment:4 Changed 9 years ago by lejav

I have the same problem with a Fedora 13 with glibc 2.12.2 : Xorg works well with addons 4.2.0 but freezes with addons 4.2.6

comment:5 Changed 9 years ago by wideaperture

Thanks for looking into it! Allan McRae  has made further progress testing the conflict with glibc, if this is helpful.

FWIW, I would've thought of Arch as a major distribution. It's on the  DistroWatch Top Ten and there are  more than 20 other active distros that are based on it and/or use its repositories. With that said, I know everyone has their pet distribution and it's not worth haggling about, so I digress. I really appreciate you looking into the issue.

comment:6 Changed 9 years ago by michael

Took a first look at this, but it wasn't very enlightening. The X server log output suggests that whatever goes wrong is in X server or libdrm code, not in VirtualBox code. Expected output at the point of the log file where the server fails is

[     xxxx] (EE) AIGLX error: vboxvideo does not export required DRI extension
[     xxxx] (EE) AIGLX: reverting to software rendering

and in your log file only the first of these is shown. No VirtualBox code should be executed in-between these two messages, and the only things which I immediately see the X.Org 1.13 code sdoing there are a shared library being unloaded, an entry being removed from a hash table (in drmClose in libdrm) and a memory structure being freed. It may well still be related to VirtualBox, and this is probably a rather rarely use path through the X server.

comment:7 Changed 9 years ago by wideaperture

Thank you, Michael. Is there any additional output that I or others experiencing this issue could provide you with that would help to troubleshoot it? It's currently the  most active  thread on the Arch Linux bug tracker, so I can probably help to scare up a few volunteers. Thanks again for your help.

comment:8 Changed 9 years ago by michael

I can reproduce this locally in a VM, and get the following back trace in gdb:

Program received signal SIGSEGV, Segmentation fault.
0xb777249b in _dl_fixup () from /lib/ld-linux.so.2
(gdb) bt
#0  0xb777249b in _dl_fixup () from /lib/ld-linux.so.2
#1  0xb77788e0 in _dl_runtime_resolve () from /lib/ld-linux.so.2
#2  0xb7253a22 in ?? () from /usr/lib/xorg/modules/extensions/libglx.so
#3  0xb724ac79 in ?? () from /usr/lib/xorg/modules/extensions/libglx.so
#4  0x080f4add in InitExtensions ()
#5  0x0806754b in ?? ()
#6  0xb73c2825 in __libc_start_main () from /usr/lib/libc.so.6
#7  0x08067af9 in _start ()

However if I rebuild and re-install the xorg-server package with debugging symbols the problem goes away. I also note that there don't seem to be any VirtualBox-related functions in the stack trace, though I don't know what symbol libglx.so was trying to resolve. Are you sure that this is a problem in VirtualBox?

comment:9 Changed 9 years ago by lejav

I am back with my fedora 13: my X session does not start with guest addons 4.2.6 (hangs with working cursor) but starts well with the guest addons 4.2.0. I have checked / diffed the various logs (system, X, xsession...) and did not find any interesting information. I can easily reproduce the problem: upgrade addon and restart the VM. It seems to be a problem behind Xorg (VBox module ?)

comment:10 Changed 9 years ago by wideaperture

Michael: Folks in the various threads I've linked to in the ticket all seemed to indicate that the problem is with VirtualBox, which is why I filed the ticket here. However, I don't personally have the expertise to authoritatively say that the problem lies with VirtualBox. I have posted a link to your comments on the Arch Linux bug tracker and hopefully the users and developers working on that end to identify the source of the problem will provide some more helpful information.

comment:11 Changed 9 years ago by benjarobin

@lejav I don't think that your problem is related to this ticket, first of all the problem only exists with glibc 2.17, second point the tty got black (no way to go it back without rebooting with a ssh shell), X fail to start (or exit quickly)... We do not see any cursor... You may wants to fill another bug report.

@michael Could you explain the procedure to obtain a gdb trace since the screen got black ? What did you do to obtain this trace.

I did run this test (as root) :

cp /usr/bin/Xorg /usr/bin/testX  #Copy of Xorg without setuid
valgrind -v --tool=memcheck testX &> /root/log

And the result do not show any Segmentation fault... Since memcheck replace the implementation of malloc, Xorg is working fine... But there was a lot of memcheck warning or error... See  http://pastebin.com/AVH9C683

If I run this test

Xorg &> /root/log2

I Got

X.Org X Server 1.13.1
Release Date: 2012-12-13
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.7.0-1-ARCH i686 
Current Operating System: Linux benjarobin-vb 3.7.3-1-ARCH #1 SMP PREEMPT Thu Jan 17 19:29:42 CET 2013 i686
Kernel command line: root=/dev/disk/by-uuid/f56f3429-fd66-4cd6-af31-648b294a84b4 ro
Build Date: 16 December 2012  04:52:09PM
 
Current version of pixman: 0.28.2
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Wed Jan 23 20:51:21 2013
(==) Using config directory: "/etc/X11/xorg.conf.d"
Initializing built-in extension Generic Event Extension
Initializing built-in extension SHAPE
Initializing built-in extension MIT-SHM
Initializing built-in extension XInputExtension
Initializing built-in extension XTEST
Initializing built-in extension BIG-REQUESTS
Initializing built-in extension SYNC
Initializing built-in extension XKEYBOARD
Initializing built-in extension XC-MISC
Initializing built-in extension SECURITY
Initializing built-in extension XINERAMA
Initializing built-in extension XFIXES
Initializing built-in extension RENDER
Initializing built-in extension RANDR
Initializing built-in extension COMPOSITE
Initializing built-in extension DAMAGE
Initializing built-in extension MIT-SCREEN-SAVER
Initializing built-in extension DOUBLE-BUFFER
Initializing built-in extension RECORD
Initializing built-in extension DPMS
Initializing built-in extension X-Resource
Initializing built-in extension XVideo
Initializing built-in extension XVideo-MotionCompensation
Initializing built-in extension XFree86-VidModeExtension
Initializing built-in extension XFree86-DGA
Initializing built-in extension XFree86-DRI
Initializing built-in extension DRI2
Loading extension GLX
Last edited 9 years ago by benjarobin (previous) (diff)

comment:12 Changed 9 years ago by michael

I got the backtrace by logging in via ssh and starting Xorg in gdb. (For your interest there is also a trick which involves having gdb read commands from a script.<1>) Running Xorg as non-root is not likely to get you far as the offending code, which I suspect is in libglx.so, will probably never be loaded.

If the Arch Linux people still think that this is a VirtualBox bug, it would be nice if one of them with experience at debugging the X server packages could comment on this ticket so that we can investigate the issue together.

<1>  http://www.x.org/wiki/Development/Documentation/ServerDebugging

comment:13 Changed 9 years ago by wideaperture

FYI, the assignment info on the Arch bug tracker ticket has now been expanded to include developers who work with Xorg packages.

comment:14 Changed 9 years ago by benjarobin

I obtain the same trace that you, maybe this is not a VirtualBox bug... I will update this ticket as soon we obtain more information

A trace with symbol :  http://pastebin.com/iJzw4edM

Last edited 9 years ago by benjarobin (previous) (diff)

comment:15 Changed 9 years ago by benjarobin

Bug should be close because not related to VirtualBox, for more detail  https://bugs.archlinux.org/task/33229

comment:16 Changed 9 years ago by michael

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

You beat me to it. I had narrowed down (from the server log file and the output from your valgrind run, redone locally with vboxvideo debug symbols) that either pSAREA or framebuffer.base must be invalid.

By the way, most or all of the errors valgrind found in vboxvideo are wrong. The uninitialised memory is actually initialised by the host, which valgrind obviously has no way of knowing.

Thanks for the feedback. I will close this ticket.

comment:17 Changed 9 years ago by lejav

For information, my problem with my fedora 13 is related to compiz and seems the same as  https://forums.virtualbox.org/viewtopic.php?f=3&t=52215

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use