Bug 84925 - Consistantly Reproduce X crash on .902 build
Summary: Consistantly Reproduce X crash on .902 build
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 9
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-02-23 22:55 UTC by Christopher Stone
Modified: 2007-04-18 16:51 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-04-07 11:46:17 UTC
Embargoed:


Attachments (Terms of Use)

Description Christopher Stone 2003-02-23 22:55:37 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030206

Description of problem:
Ok, there has been a lot of stability problems with XFree86 that comes with
latest Phoebe.  However, I have noticed one crash which I am able to
consistantly reproduce.  I have also upgraded to the Rawhide XFree86 RPMs and
the crash still occurs.  I am currently running XFree86-4.2.99.902-20030220.1

The crash occurs when running xmame (an unsupported app). 

xmame.x11 -noloadconfig -noxvext -x11-mode 1 -noartwork puckman

this will cause X to crash when xmame exits every time.  Please advise me as to
how to debug.  I have tried strace, but the X crash causes the strace output to
not flush.  Likewise running xmame in a debugger would also not work because of
the X crash.

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


How reproducible:
Always

Steps to Reproduce:
1.  download xmame 0.65 at x.mame.net and puckman ROM images at mame.dk
2.  compile the x11 version of xmame and enable the X11_DGA and X11_XV options
3.  run ./xmame.x11 -noloadconfig -noxvext -x11-mode 1 -noartwork puckman


Actual Results:  X crashes when xmame.x11 exists

Expected Results:  exists normally

Additional info:

Was working properly with 8.0.93

Comment 1 Christopher Stone 2003-04-07 03:35:29 UTC
fixed with redhat9


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