Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Google earth crashes X windows - solved
193 views
Skip to first unread message
The Natural Philosopher
Apr 27, 2013, 7:55:45 AM4/27/13
to
I am posting this so the next poor sod wont have to spend a few hours
puzzling out why a previously working google-earth on Linux subsequently
decided that getting as far as the splash screen was more than enough
and destroyed the x window server out of what appeared to be sheer spite.
The setup was linux mint 13 X_64, but as you will see, that was
moderately irrelevant.
I found this to be a not uncommon problem, and tried every single
version of google earth available. All behaved the same.
Finally wondering what I had upgraded since it last worked, I tried the
very latest NVIDIA driver..I had been on 313.26 but installing 313.30
immediately solved the problem.
the fix appears to be this:
"Fixed CVE-2013-0131: NVIDIA UNIX GPU Driver ARGB Cursor Buffer Overflow
in "NoScanout" Mode. This buffer overflow, which occurred when an X
client installed a large ARGB cursor on an X server running in NoScanout
mode, could cause a denial of service (e.g., an X server segmentation
fault), or could be exploited to achieve arbitrary code execution."
what that means I have no idea, but presumably google earth does this.
--
Ineptocracy
(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.
puzzling out why a previously working google-earth on Linux subsequently
decided that getting as far as the splash screen was more than enough
and destroyed the x window server out of what appeared to be sheer spite.
The setup was linux mint 13 X_64, but as you will see, that was
moderately irrelevant.
I found this to be a not uncommon problem, and tried every single
version of google earth available. All behaved the same.
Finally wondering what I had upgraded since it last worked, I tried the
very latest NVIDIA driver..I had been on 313.26 but installing 313.30
immediately solved the problem.
the fix appears to be this:
"Fixed CVE-2013-0131: NVIDIA UNIX GPU Driver ARGB Cursor Buffer Overflow
in "NoScanout" Mode. This buffer overflow, which occurred when an X
client installed a large ARGB cursor on an X server running in NoScanout
mode, could cause a denial of service (e.g., an X server segmentation
fault), or could be exploited to achieve arbitrary code execution."
what that means I have no idea, but presumably google earth does this.
--
Ineptocracy
(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.
Message has been deleted
The Natural Philosopher
Apr 27, 2013, 11:51:37 AM4/27/13
to
On 27/04/13 14:30, Darren Salt wrote:
> I demand that The Natural Philosopher may or may not have written...
> buffer space. They seem to think that this is, potentially, exploitable. You
> evidently saw it segfault; check /var/log/Xorg.0.log (or, if you've started
> *one* X server instance since the crash, /var/log/Xorg.0.log.old).
honestly, not necessary. 'exception at ffffcao:55754678 is not really
helpful is it?
> As always, if it crashes X, the bug is in X or in a library which X uses.
>
That is *far* more helpful: If that had occurred to me in that firm I
wouldnt have spent hours fiddling with various googleearth rels.
I'd have thought 'which part of the X sub system have you buggered with
recently'
I did note some very strange screen artefacts appearing temporarily when
I reloaded X..suggesting video level corruption.
> I demand that The Natural Philosopher may or may not have written...
>
>> I am posting this so the next poor sod wont have to spend a few hours
>> puzzling out why a previously working google-earth on Linux subsequently
>> decided that getting as far as the splash screen was more than enough and
>> destroyed the x window server out of what appeared to be sheer spite.
> [snip]
>> I am posting this so the next poor sod wont have to spend a few hours
>> puzzling out why a previously working google-earth on Linux subsequently
>> decided that getting as far as the splash screen was more than enough and
>> destroyed the x window server out of what appeared to be sheer spite.
>> the fix appears to be this:
>> "Fixed CVE-2013-0131: NVIDIA UNIX GPU Driver ARGB Cursor Buffer Overflow in
>> "NoScanout" Mode. This buffer overflow, which occurred when an X client
>> installed a large ARGB cursor on an X server running in NoScanout mode,
>> could cause a denial of service (e.g., an X server segmentation fault), or
>> could be exploited to achieve arbitrary code execution."
>> what that means I have no idea, but presumably google earth does this.
> An image used for the mouse pointer is too large to fit in the available
>> "Fixed CVE-2013-0131: NVIDIA UNIX GPU Driver ARGB Cursor Buffer Overflow in
>> "NoScanout" Mode. This buffer overflow, which occurred when an X client
>> installed a large ARGB cursor on an X server running in NoScanout mode,
>> could cause a denial of service (e.g., an X server segmentation fault), or
>> could be exploited to achieve arbitrary code execution."
>> what that means I have no idea, but presumably google earth does this.
> buffer space. They seem to think that this is, potentially, exploitable. You
> evidently saw it segfault; check /var/log/Xorg.0.log (or, if you've started
> *one* X server instance since the crash, /var/log/Xorg.0.log.old).
honestly, not necessary. 'exception at ffffcao:55754678 is not really
helpful is it?
> As always, if it crashes X, the bug is in X or in a library which X uses.
>
That is *far* more helpful: If that had occurred to me in that firm I
wouldnt have spent hours fiddling with various googleearth rels.
I'd have thought 'which part of the X sub system have you buggered with
recently'
I did note some very strange screen artefacts appearing temporarily when
I reloaded X..suggesting video level corruption.
unruh
Apr 27, 2013, 12:25:45 PM4/27/13
to
On 2013-04-27, The Natural Philosopher <t...@invalid.invalid> wrote:
> On 27/04/13 14:30, Darren Salt wrote:
...
> On 27/04/13 14:30, Darren Salt wrote:
>
>> As always, if it crashes X, the bug is in X or in a library which X uses.
>>
> That is *far* more helpful: If that had occurred to me in that firm I
> wouldnt have spent hours fiddling with various googleearth rels.
> I'd have thought 'which part of the X sub system have you buggered with
> recently'
>
> I did note some very strange screen artefacts appearing temporarily when
> I reloaded X..suggesting video level corruption.
You are lucky. My X crashes also stop my keyboard from working, but not
>> As always, if it crashes X, the bug is in X or in a library which X uses.
>>
> That is *far* more helpful: If that had occurred to me in that firm I
> wouldnt have spent hours fiddling with various googleearth rels.
> I'd have thought 'which part of the X sub system have you buggered with
> recently'
>
> I did note some very strange screen artefacts appearing temporarily when
> I reloaded X..suggesting video level corruption.
my mouse. Unfortunately there is nothing for my mouse to do except move,
since all of the xserssion, including all icons, is dead, and the
keyboard is dead as well. The big red switch is the only option.Even
trying to kill X from an outside ssh session does not work.
>
Aragorn
Apr 27, 2013, 1:18:30 PM4/27/13
to
On Saturday 27 April 2013 18:25, unruh conveyed the following to
comp.os.linux.setup...
Normally, the SysRq sequences can still offer solace in such a
situation, since SysRq sequences are not sent to the application - i.e.
X11 - but to the kernel directly.
If the mouse cursor still moves, then the kernel is still alive, and
then it is definitely advisable to try the SysRq approach first before
you decide to throw the Big Red Switch ™.
--
= Aragorn =
GNU/Linux user #223157 - http://www.linuxcounter.net
comp.os.linux.setup...
situation, since SysRq sequences are not sent to the application - i.e.
X11 - but to the kernel directly.
If the mouse cursor still moves, then the kernel is still alive, and
then it is definitely advisable to try the SysRq approach first before
you decide to throw the Big Red Switch ™.
--
= Aragorn =
GNU/Linux user #223157 - http://www.linuxcounter.net
The Natural Philosopher
Apr 27, 2013, 1:25:44 PM4/27/13
to
crashing usually..more often something somewhere gets stuck waiting for
an interrupt or something. Classic case is when I try and access a
remote NFS mount and the broadband link has 'vanished'
In this case I was bounced back to the console and then the display
manager restarted X and gave me a login screen.
unruh
Apr 27, 2013, 5:18:14 PM4/27/13
to
>
Unfortunately the keyboard is frozen together with the X screen. I think
I tried the sysreq but am not sure right now. (Eg on the keyboard,
pressing num lock or cap lock do not change the status of the lights on
the keyboard at all, which makes me think that the whole keyboard is
frozen and no just it report to X)
The Natural Philosopher
Apr 27, 2013, 7:53:03 PM4/27/13
to
bad hardware or bad device driver
0 new messages