Return to BSD News archive
Xref: sserve comp.unix.pc-clone.32bit:3746 comp.os.386bsd.bugs:1089 comp.windows.x.i386unix:2422 Newsgroups: comp.unix.pc-clone.32bit,comp.os.386bsd.bugs,comp.windows.x.i386unix Path: sserve!newshost.anu.edu.au!munnari.oz.au!bruce.cs.monash.edu.au!merlin!mel.dit.csiro.au!its.csiro.au!dmssyd.syd.dms.CSIRO.AU!metro!news From: dawes@physics.su.OZ.AU (David Dawes) Subject: Re: XFree 1.3 crash (SIGFPE floting point exception) Message-ID: <1993Jul10.100039.26329@ucc.su.OZ.AU> Keywords: XFree86 1.3, X11 Sender: news@ucc.su.OZ.AU Nntp-Posting-Host: physics.su.oz.au Organization: School of Physics, University of Sydney, Australia References: <2516@alderan.sdata.de> Date: Sat, 10 Jul 1993 10:00:39 GMT Lines: 46 In article <2516@alderan.sdata.de> chris@alderan.sdata.de (Christoph Splittgerber) writes: >Hello World ! > >Yesterday I installed XFree86 1.3 on an 66 MHz EISA (ISC 3.0.1) >with a localbus ET4000 Virtual 1024x1024 (all SpeedUp's). > >The performance is really impressive !!! > >Now to my problem: The server dies with an floting point exception >when running x11perf in the "wdcircle100" test (100-pixel diameter >dashed circle, line width 10 (30 on, 20 off)). > >Has anybody also seen this ? I have seen this on 386BSD when using a server compiled with gcc-1.39, but the problem doesn't seem to occur on 386BSD when the server is complied with gcc-2.3.3. I don't know if this is related to the problem you are seeing or not. Can you run the server under gdb and get a stack trace? The stack trace I get is: Program received signal 8, Floating point exception 0xc3057 in miFillSppPoly (1062912, 1052288, 17, 1146880, 5, 5, 0, 1078525952, 0, 1078525952) (gdb) bt #0 0xc3057 in miFillSppPoly (1062912, 1052288, 17, 1146880, 5, 5, 0, 1078525952, 0, 1078525952) #1 0xb406c in miarc:miRoundCap () #2 0xb3ecb in miarc:miArcCap (1062912, 1052288, 1290472, 1, 5, 5, 0, 1078525952, 0, 1078525952) #3 0xb333c in miPolyArc () #4 0xcd2bd in misprite:miSpritePolyArc () After a little debugging, it seems that the casting from double to int is rounding rather than truncating (ie -4.9 is being converted to -5 where the expected conversion is -4). This causes the ICEIL function to return an unexpected result, and the consequence of this is that some double variables don't get initialised. This seems to lead to the SIGFPU. As I say, I don't know if this is relevant to your situation or not. I get the crash after the first circle is drawn. Looking at it closely the first 4 rounded end-caps have been drawn. The crash occurs while drawing the fifth. David -- ------------------------------------------------------------------------------ David Dawes <dawes@physics.su.oz.au> DoD#210 | Phone: +61 2 692 2639 School of Physics, University of Sydney, Australia | Fax: +61 2 660 2903 ------------------------------------------------------------------------------