There are refcounting problemes with latest code (most likely caued by
http://darcs.ghostscript.com/darcsweb.cgi?r=fitz;a=commitdiff;h=20090630002357-f546f-340ed1793203dab30d21977ba4cc9a2c3e7045e0.gz)

It happens with any PDF: when closing PDF (in pdf_closexref) some object will be
read from and written to after being freed. This is easily caught with debug crt
in msvc 2008, which says:
"HEAP[sumatrapdf.exe]: HEAP: Free Heap block 1148ad0 modified at 1148af8 after
it was freed
Windows has triggered a breakpoint in sumatrapdf.exe.

This may be due to a corruption of the heap, which indicates a bug in
sumatrapdf.exe or any of the DLLs it has loaded."

	msvcr90d.dll!_free_base(void * pBlock=0x01148a80)  Line 109 + 0x13 bytes	C
 	msvcr90d.dll!_free_dbg_nolock(void * pUserData=0x01148aa0, int nBlockUse=1) 
Line 1426 + 0x9 bytes	C++
 	msvcr90d.dll!_free_dbg(void * pUserData=0x01148aa0, int nBlockUse=1)  Line
1258 + 0xd bytes	C++
 	msvcr90d.dll!free(void * pUserData=0x01148aa0)  Line 49 + 0xb bytes	C++
 	SumatraPDF.exe!fz_free(void * p=0x01148aa0)  Line 21 + 0xc bytes	C
 	SumatraPDF.exe!fz_dropobj(fz_obj_s * o=0x01148aa0)  Line 100 + 0x9 bytes	C
 	SumatraPDF.exe!fz_freedict(fz_obj_s * obj=0x01148788)  Line 399 + 0x13 bytes	C
 	SumatraPDF.exe!fz_dropobj(fz_obj_s * o=0x01148788)  Line 94 + 0x9 bytes	C
 	SumatraPDF.exe!pdf_flushxref(pdf_xref_s * xref=0x0114e000, int force=1)  Line
109 + 0x16 bytes	C
 	SumatraPDF.exe!pdf_closexref(pdf_xref_s * xref=0x0114e000)  Line 54 + 0xb bytes	C
 	SumatraPDF.exe!PdfEngine::~PdfEngine()  Line 174 + 0xc bytes	C++
 	SumatraPDF.exe!PdfEngine::`scalar deleting destructor'()  + 0x16 bytes	C++
 	SumatraPDF.exe!DisplayModel::~DisplayModel()  Line 207 + 0x1e bytes	C++
 	SumatraPDF.exe!DisplayModel::`scalar deleting destructor'()  + 0x16 bytes	C++
 	SumatraPDF.exe!CloseWindow(WindowInfo * win=0x01149218, bool quitIfLast=false)
 Line 4097 + 0x1f bytes	C++

libc with debug malloc options will also detect this but the best tool to catch
this is valgrind, which will detect the problem at the time freed memory is read
from or being written to.

Empirically, the following patch fixes the issue:

Index: mupdf/pdf_pagetree.c
===================================================================
--- mupdf/pdf_pagetree.c        (revision 1177)
+++ mupdf/pdf_pagetree.c        (working copy)
@@ -200,9 +200,6 @@
        error = loadpagetree(xref, p, inherit, pages, treeref, &pagenum);
        if (error) { error = fz_rethrow(error, "cannot load pagetree (%d %d R)",
fz_tonum(treeref), fz_togen(treeref)); goto cleanup; }

-       fz_dropobj(pages);
-       fz_dropobj(catalog);
-
        pdf_logpage("}\n", count);

        *pp = p;