Possibly relevant gdb output:

(gdb) where
#0  refs_clear_marks (cmem=0x102022c58, vptr=0x10308aba8, size=400, pstype=0x10123a520) at igcref.c:118
#1  0x000000010018ddb2 in gc_objects_clear_marks (mem=0x102022c58, cp=0x1019472f0) at igc.c:622
#2  0x000000010018c10c in gs_gc_reclaim (pspaces=0x102071f78, global=1) at igc.c:266
#3  0x00000001002ca05c in context_reclaim (pspaces=0x102071f78, global=1) at zcontext.c:280
#4  0x000000010012721c in gs_vmreclaim (dmem=0x102071f70, global=1) at ireclaim.c:155
#5  0x0000000100126f14 in ireclaim (dmem=0x102071f70, space=-1) at ireclaim.c:77
#6  0x000000010011cbf0 in interp_reclaim (pi_ctx_p=0x10190cc18, space=-1) at interp.c:432
#7  0x0000000100122370 in interp (pi_ctx_p=0x10190cc18, pref=0x7fff5fbfeac8, perror_object=0x7fff5fbfed60) at interp.c:1704
#8  0x000000010011cf14 in gs_call_interp (pi_ctx_p=0x10190cc18, pref=0x7fff5fbfec38, user_errors=1, pexit_code=0x7fff5fbfed70, perror_object=0x7fff5fbfed60) at interp.c:501
#9  0x000000010011cccc in gs_interpret (pi_ctx_p=0x10190cc18, pref=0x7fff5fbfec38, user_errors=1, pexit_code=0x7fff5fbfed70, perror_object=0x7fff5fbfed60) at interp.c:459
#10 0x000000010010ade9 in gs_main_interpret (minst=0x10190cb80, pref=0x7fff5fbfec38, user_errors=1, pexit_code=0x7fff5fbfed70, perror_object=0x7fff5fbfed60) at imain.c:235
#11 0x000000010010c21f in gs_main_run_string_end (minst=0x10190cb80, user_errors=1, pexit_code=0x7fff5fbfed70, perror_object=0x7fff5fbfed60) at imain.c:609
#12 0x000000010010c041 in gs_main_run_string_with_length (minst=0x10190cb80, str=0x101917510 "<2e2f4275673639333432322e706466>.runfile", length=40, user_errors=1, pexit_code=0x7fff5fbfed70, perror_object=0x7fff5fbfed60) at imain.c:567
#13 0x000000010010bf56 in gs_main_run_string (minst=0x10190cb80, str=0x101917510 "<2e2f4275673639333432322e706466>.runfile", user_errors=1, pexit_code=0x7fff5fbfed70, perror_object=0x7fff5fbfed60) at imain.c:549
#14 0x0000000100110747 in run_string (minst=0x10190cb80, str=0x101917510 "<2e2f4275673639333432322e706466>.runfile", options=3) at imainarg.c:866
#15 0x0000000100110602 in runarg (minst=0x10190cb80, pre=0x1007f76d0 "", arg=0x7fff5fbffb3c "./Bug693422.pdf", post=0x1007ed9da ".runfile", options=3) at imainarg.c:855
#16 0x000000010011013f in argproc (minst=0x10190cb80, arg=0x7fff5fbffb3c "./Bug693422.pdf") at imainarg.c:788
#17 0x000000010010df86 in gs_main_init_with_args (minst=0x10190cb80, argc=5, argv=0x7fff5fbff940) at imainarg.c:226
#18 0x0000000100001832 in main (argc=5, argv=0x7fff5fbff940) at gs.c:96
(gdb)

Neither valgrind nor memento had any interesting to say about the problem.

I don't think it has actually entered an infinte loop, its just very slow.

The problem is that its yet another insane Cairo file, and it nests deeper than our graphics state stack, with the result that we throw errors. So even if you left it long enough to complete, the output would be incorrect.

Ps2write, which collapses all the transparency into images, works fine with this file.

We've seen this before with Cairo files, and the only proper solution is to make our graphics state stack dynamic instead of static. However that's a fairly big task (a simplistic hack fell apart very quickly) involving garbage collection, so I'm leaving this open to remind me to do that work.

This command also generates a metric boat load of warnings:

   **** Error reading a content stream. The page may be incomplete.
   **** Error reading a content stream. The page may be incomplete.
   **** Warning: Form stream has unbalanced q/Q operators (too many q's)
   **** Error reading a content stream. The page may be incomplete.
   **** Error reading a content stream. The page may be incomplete.
   **** Warning: Form stream has unbalanced q/Q operators (too many q's)
   **** Error reading a content stream. The page may be incomplete.
   **** Error reading a content stream. The page may be incomplete.
   **** Warning: Form stream has unbalanced q/Q operators (too many q's)
   **** Error reading a content stream. The page may be incomplete.
...

(In reply to comment #4)
> This command also generates a metric boat load of warnings:
> 
>    **** Error reading a content stream. The page may be incomplete.
>    **** Error reading a content stream. The page may be incomplete.
>    **** Warning: Form stream has unbalanced q/Q operators (too many q's)

pdfwrite is returning an error, but the PDF interpreter is configured to ignore these errors and continue by default. This aborts the current stream.

See comment #3 for a brief explanation of the problem. Because of the way this file is constructed (ugly slow and horrible) this causes a lot of these warnings.

Use -dPDFSTOPONERROR and you'll get a simple error instead.

*** Bug 694531 has been marked as a duplicate of this bug. ***

Fixed in commit dfd7fc9fe152245256e437141dd7780c8313c971