The SEGV only occurs when paging through the document from page 1 on via the
space bar.  Jumping around with F and B seems to avoid it.

Backtrace is:

#0  0x08090a7c in fz_optimizetree (tree=0x3fe0) at fitz/node_optimize.c:230
#1  0x0806c93b in pdf_loadpattern (patp=0xbfa058d4, xref=0x8519010, dict=0x8948cc8, 
    stmref=0x8948cc8) at mupdf/pdf_pattern.c:142
#2  0x0805bd68 in preloadpattern (xref=0x8519010, ref=0x8948cc8) at
mupdf/pdf_resources.c:85
#3  0x0805c868 in pdf_loadresources (rdbp=0x87e2488, xref=0x8519010, orig=0x87e7e28)
    at mupdf/pdf_resources.c:357
#4  0x08073a21 in pdf_loadxobject (formp=0xbfa05a20, xref=0x8519010,
dict=0x8896168, 
    ref=0x892f550) at mupdf/pdf_xobject.c:78
#5  0x0805bfc4 in preloadxobject (xref=0x8519010, ref=0x892f550) at
mupdf/pdf_resources.c:137
#6  0x0805c9c4 in pdf_loadresources (rdbp=0xbfa05ad4, xref=0x8519010,
orig=0x8521788)
    at mupdf/pdf_resources.c:391
#7  0x0805ad68 in pdf_loadpage (pagep=0x84fe0c8, xref=0x8519010, dict=0x8521668)
    at mupdf/pdf_page.c:216
#8  0x0804e230 in pdfapp_showpage (app=0x84fe0a0, loadpage=1, drawpage=1)
    at apps/common/pdfapp.c:262
#9  0x0804ee6d in pdfapp_onkey (app=0x84fe0a0, c=32) at apps/common/pdfapp.c:508
#10 0x0804b9b1 in onkey (c=32) at apps/unix/x11pdf.c:443
#11 0x0804bf22 in main (argc=2, argv=0xbfa05ea4) at apps/unix/x11pdf.c:591

At level#0 of the backtrace, I get:

(gdb) p tree
$9 = (fz_tree *) 0x3fe0
(gdb) p *tree
Cannot access memory at address 0x3fe0

Going up a level, the pat->tree does indeed contain 0x3fe0, and there is nothing
at that address.  It looks like pat->tree is somehow clobbered.

I also tried running with DONTOPT=1 in the environment.  In that case the
backtrace looks like:

(gdb) where
#0  0x0809262f in fz_keeptree (tree=0x3fe0) at fitz/node_tree.c:23
#1  0x0808fe4c in fz_newlinknode (nodep=0xbfc29ac4, subtree=0x3fe0) at
fitz/node_misc2.c:174
#2  0x0807c941 in addpatternshape (gs=0x89e76d8, shape=0x873ae08, pat=0x87bea38,
cs=0x84f7540, 
    v=0x89e7828) at mupdf/pdf_build.c:379
#3  0x0807cf8b in pdf_addfillshape (gs=0x89e76d8, shape=0x873ae08) at
mupdf/pdf_build.c:510
#4  0x0807d7cf in pdf_showpath (csi=0x89e72e8, doclose=0, dofill=1, dostroke=0,
evenodd=0)
    at mupdf/pdf_build.c:727
#5  0x08078099 in runkeyword (csi=0x89e72e8, xref=0x8519010, rdb=0x87e8988,
buf=0xbfc29fc0 "f")
    at mupdf/pdf_interpret.c:1124
#6  0x08079786 in pdf_runcsi (csi=0x89e72e8, xref=0x8519010, rdb=0x87e8988,
file=0x88974f8)
    at mupdf/pdf_interpret.c:1381
#7  0x0807453d in runxobject (csi=0x89e72e8, xref=0x8519010, xobj=0x87c8250)
    at mupdf/pdf_interpret.c:213
#8  0x08077566 in runkeyword (csi=0x89e72e8, xref=0x8519010, rdb=0x89afd30, 
    buf=0xbfc3a430 "Do") at mupdf/pdf_interpret.c:933
#9  0x08079786 in pdf_runcsi (csi=0x89e72e8, xref=0x8519010, rdb=0x89afd30,
file=0x88bd758)
    at mupdf/pdf_interpret.c:1381
#10 0x0805a7df in runmany (csi=0x89e72e8, xref=0x8519010, rdb=0x89afd30,
list=0x8896e78)
    at mupdf/pdf_page.c:83
#11 0x0805a93f in loadpagecontents (treep=0xbfc4a518, xref=0x8519010,
rdb=0x89afd30, 
    ref=0x8521750) at mupdf/pdf_page.c:116
#12 0x0805adda in pdf_loadpage (pagep=0x84fe0c8, xref=0x8519010, dict=0x8521668)
    at mupdf/pdf_page.c:226
#13 0x0804e230 in pdfapp_showpage (app=0x84fe0a0, loadpage=1, drawpage=1)
    at apps/common/pdfapp.c:262
#14 0x0804ee6d in pdfapp_onkey (app=0x84fe0a0, c=32) at apps/common/pdfapp.c:508
#15 0x0804b9b1 in onkey (c=32) at apps/unix/x11pdf.c:443
#16 0x0804bf22 in main (argc=2, argv=0xbfc4a8f4) at apps/unix/x11pdf.c:591

As you can see, tree has the same bogus value as w/o DONTOPT.

The segv happens for both release and debug builds.

My compile is with -march=pentium3 -O2 for release and -march=pentirum3 -O0
-ggdb for debug.  (as you can guess, that is -m32).

I am currently at:

Thu Jul  2 17:16:48 EDT 2009  tor@ghostscript.com
  * More reference counting cleanups.


(The file is encrypted with an empty user pass; before today’s commits it failed
 due to the infinite loop bug.)