Bug 139832 - bzflag continues to run after X has exited
Summary: bzflag continues to run after X has exited
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: bzflag
Version: 3
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Alan Cox
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-11-18 11:27 UTC by Sitsofe Wheeler
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-04-26 18:02:39 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
strace of errant bzflag process (4.21 KB, text/plain)
2004-11-18 13:35 UTC, Sitsofe Wheeler
no flags Details

Description Sitsofe Wheeler 2004-11-18 11:27:24 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Gecko/20040804 Galeon/1.3.17

Description of problem:
bzflag has been engaged in a CPU war with gam_server even though the
user X is no longer running. Since I wasn't the user using the machine
when this happened I'm not sure of how this came about (e.g. maybe X
died) but rather I'm looking at the aftermath.

Version-Release number of selected component (if applicable):
bzflag-1.10.6-2

How reproducible:
Didn't try

Steps to Reproduce:
1. Presumably start bzflag
2. Restart X?

Actual Results:  bzflag continues to run even though X is gone.

Expected Results:  bzflag to quit itself like the GNOME bits did.

Additional info:

NOTE: NVIDIA drivers 1.0-6629 are being used on this machine. Now
while they may be the cause for X quitting (I don't know) bzflag
should not still be running. I'm really hoping this doesn't get closed
on bug 73733  just because of that...

The process is still running now so if necessary I can attach strace
to it if that would help.

Comment 1 Alan Cox 2004-11-18 13:16:10 UTC
It'll probably end up in 73733 but I'd appreciate an strace just to
confirm that.


Comment 2 Sitsofe Wheeler 2004-11-18 13:35:25 UTC
Created attachment 106953 [details]
strace of errant bzflag process

Comment 3 Alan Cox 2004-11-18 13:37:15 UTC
What are the other threads doing. Thats doing audio and not seeing any
sign of an X socket close.


Comment 4 Sitsofe Wheeler 2004-11-18 13:43:02 UTC
After attaching gdb and doing info threads I see nothing. The gdb
backtrace was this:
#0  0x006317a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x007004f3 in __read_nocancel () from /lib/tls/libc.so.6
#2  0x08118051 in std::basic_iostream<char, std::char_traits<char>
>::~basic_iostream ()
#3  0xfeeb3ed0 in ?? ()
#4  0x00000018 in ?? ()
#5  0x08106fcf in std::basic_iostream<char, std::char_traits<char>
>::~basic_iostream ()
#6  0x00000000 in ?? ()

So I'm not sure what to make of that other than "it's hosed". If you
want to dig further (and maybe faster) than I am you can take a look
at zinc after sshing to sucs.org as that's where this is.

Comment 5 Sitsofe Wheeler 2005-04-26 18:02:39 UTC
This has never recurred and everyone plays bzflag2 now so if it is a bug we
won't  see it. Closing this bug WORKSFORME.


Note You need to log in before you can comment on or make changes to this bug.