marshall@software.ORG (Eric Marshall) (10/05/88)
It sounds weird to me, but both of the following programs
cause the server to dump core:
[ 4.00000 ] 0 setdash
100 100 moveto
200 100 lineto stroke
and
[ 00004.0 ] 0 setdash
100 100 moveto
200 100 lineto stroke
Why? Because there are too many insignificant zeros in
the value specified in the dash pattern array! No, really. If
you remove one of the insignificant trailing/leading zeros from
either program, the program executes correctly.
I am running on a Sun 3/160 running NeWS 1.1 under SunOS 3.4.
Some dbx information concerning the core image follows.
Eric Marshall
Software Productivity Consortium
1880 North Campus Commons Drive
Reston, VA 22091
(703) 391-1838
CSNET: marshall@software.org
ARPANET: marshall%software.org@relay.cs.net OR
@relay.cs.net:marshall@software.org
------------------------------------------------------------------------------
The OSF.
Just say NO.
------------------------------------------------------------------------------
% dbx /usr/NeWS/bin/news_server-mc68010.debug core
Reading symbolic information...
Read 37102 symbols
(dbx) where
_malloc_at_addr(0xfffc4000) at 0x7dfee
malloc(0xfffc355c) at 0x7da1b
realloc(0x240650, 0xfffc355c) at 0x7dd91
enlarge_path(gc = 0xa9170), line 129 in "flattenpath.c"
cs_dashpath(gc = 0x12e90c), line 262 in "flattenpath.c"
PostScript(ee = 0x12e8c4), line 3066 in "operators.h"
run_process(ee = 0x12e8c4), line 431 in "sched.c"
run_readers(read_mask = 0xefffd44), line 480 in "sched.c"
RunScheduler(), line 162 in "sched.c"
main(argc = 1, argv = 0xefffd94, 0xefffd9c), line 1139 in "PostScript.c"
(dbx) dump
gc = 0xa9170
(dbx) quit
%msc@canth.SGI.COM (Mark Callow) (10/10/88)
In article <8810040723.AA04993@brillig.umd.edu>, marshall@software.ORG (Eric Marshall) writes: > > It sounds weird to me, but both of the following programs > cause the server to dump core: > > [ 4.00000 ] 0 setdash > 100 100 moveto > 200 100 lineto stroke > and > [ 00004.0 ] 0 setdash > 100 100 moveto > 200 100 lineto stroke The following change fixes this problem (thanks to James for the fix) In the routine setdash() in server/nucleus/misc.c change case real_type: buf[i] = optop->value.real; break; to case real_type: buf[i] = fractf(optop->value.real); break; -- From the TARDIS of Mark Callow msc@sgi.sgi.com, ...{ames,decwrl,sun}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."