I don't deny that a crash is undesirable, but is -dLastPage meant to do anything useful for PXL files ? Its documented in use.htm for PDF files, I didn't know it worked for PXL files as well.

Tried this with the current HEAD revision, on Windows, and the test file 5148.pxl without problem. Hin-Tak can you point me to a file which fails please ? Even if it only fails on Linux I need to be able to see the problem.

It has gone worse - running any file (e.g tools/pattern.pxl) without -dLastPage=1 give this: 

----------------------------------
#0  0x00000000004046d6 in ps_impl_get_minst (mem=0x31e6c38) at ../psi/psitop.c:324
324	    return psi->minst;
(gdb) bt
#0  0x00000000004046d6 in ps_impl_get_minst (mem=0x31e6c38) at ../psi/psitop.c:324
#1  0x00000000004ae984 in get_minst_from_memory (mem=0x31e6c38) at ../gs/psi/imain.c:63
#2  0x00000000004aea0f in get_op_array (mem=0x31e6c38, size=1712) at ../gs/psi/imain.c:96
#3  0x00000000004c8cf9 in op_index_ref (mem=0x31e6c38, index=1712, pref=0x320cdc8) at ../gs/psi/iutil.c:640
#4  0x00000000004e255c in zmakeoperator (i_ctx_p=0x3223f60) at ../gs/psi/zmisc.c:307
#5  0x00000000004bab9b in call_operator (op_proc=0x4e232b <zmakeoperator>, i_ctx_p=0x3223f60) at ../gs/psi/interp.c:118
#6  0x00000000004bddea in interp (pi_ctx_p=0x31e5198, pref=0x7fffb09030f0, perror_object=0x7fffb0903140) at ../gs/psi/interp.c:1550
#7  0x00000000004bb2e9 in gs_call_interp (pi_ctx_p=0x31e5198, pref=0x7fffb09030f0, user_errors=1, pexit_code=0x7fffb090315c, perror_object=0x7fffb0903140)
    at ../gs/psi/interp.c:508
#8  0x00000000004bb0fc in gs_interpret (pi_ctx_p=0x31e5198, pref=0x7fffb09030f0, user_errors=1, pexit_code=0x7fffb090315c, perror_object=0x7fffb0903140) at ../gs/psi/interp.c:466
#9  0x00000000004aee7c in gs_main_interpret (minst=0x31e5100, pref=0x7fffb09030f0, user_errors=1, pexit_code=0x7fffb090315c, perror_object=0x7fffb0903140)
    at ../gs/psi/imain.c:240
#10 0x00000000004af7a8 in gs_run_init_file (minst=0x31e5100, pexit_code=0x7fffb090315c, perror_object=0x7fffb0903140) at ../gs/psi/imain.c:483
#11 0x00000000004aef78 in gs_main_init2 (minst=0x31e5100) at ../gs/psi/imain.c:275
#12 0x00000000004b0a79 in gs_main_init_with_args (minst=0x31e5100, argc=4, argv=0x7fffb0903bf0) at ../gs/psi/imainarg.c:223
#13 0x0000000000404509 in ps_impl_allocate_interp_instance (instance=0x7fffb0903fc0, interp=0x1941978, mem=0x31b73d8) at ../psi/psitop.c:225
#14 0x0000000000866a5d in pl_allocate_interp_instance (instance=0x7fffb0903fc0, interp=0x1941978, mem=0x31b73d8) at ../pl/pltop.c:61
#15 0x00000000008b4708 in pl_main_universe_init (universe=0x7fffb0903fa0, err_str=0x7fffb0904620 "\"", mem=0x31b73d8, pdl_implementation=0xa2eb20, pjl_instance=0x31b8130, 
    inst=0x7fffb09050f0, pl_pre_finish_page=0x8b5ea9 <pl_pre_finish_page>, pl_post_finish_page=0x8b604c <pl_post_finish_page>) at ../pl/plmain.c:546
#16 0x00000000008b3ba0 in pl_main (argc=2, argv=0x7fffb09052d8) at ../pl/plmain.c:280
#17 0x00000000008b624c in main (argc=2, argv=0x7fffb09052d8) at ../pl/plmain.c:1311
(gdb) 
------------

That has to mean psi isn't filled with the right stuff.

When I run the switch as reported, I forgot that -dLastPage/-dFirstPage are for the interpreter, not for the writer - I mistakenly thought -dLastPage=1 would just write the first page out. (and it probably should work that way, if it is implemented).

Hin-Tak, are you using a language switch build ? 

I can't see why you would get to 'ps_impl_allocate_interp_instance' in the PCL interpreter, since that is (I think) the PostScript interpreter.

OK, forget that, I see you are indeed using the language switch build (pspcl6), I was testing using pcl6, I've never tried the language switch build.

OK, I don't believe at the moment that this has anything to do with pdfwrite, the language switch build seems to be broken completely.

Although this is happening in the PostScript interpreter, it seems to be caused because the pl_main_universe_t->curr_instance is NULL. That gets cast to a PostScript interpreter instance, and then dereferenced, causing the segment fault. This happens on Windows as well as Linux.

For me this happens without using the pdfwrite device, and occurs during initialisation of the PostScript world. This isn't an area I know anything about, but I'll spend some time poking it, until someone more qualified comes along.

I *think* that the language_switch build got broken in revision 11146 where, as part of the globals elimination, a new function was added for getting the array of deined operators. This function uses get_minst_from_memory which assumes a current instance of an interpreter, but I don't think the language_switch build has a current instance, until an interpreter is selected (or something like that).

So I've backed out may language_switch code to revision 11141 and am looking again at -dLastPage.

For me the revision 11141 code fails with pdfwrite, its trying to do some vm cleanup and appears to be font-related. I get a GPF in igc_reloc_struct, called from font_reloc_ptrs.

I guess the language_switch build must run the garbage collector ?

r11366 relevant? Just a note here to re-check.

This appears to be fixed. The file tools/pattern.pxl with -dLastPage=1 now works correctly with the pdfwrite device and the Windows display device.