I cannot reproduce this (with current master or commit 88d933d6). It does not appear to hit either of the two lines in question at all and exits with 0. What gives...
Because the piece of code in question contains an obvious flaw regardless (XXX above), I'm looking at its origin. This section mainly originates from commits 285b6f89 and ddf109c3. The former introduces the branch on contents->token_type == TT_Objstm (calls parse_rsrcdict rather than dissecting an HSequence) and the latter works around a crash by essentially short-circuiting the TT_SEQUENCE case, leaving the sequence code as the broken else case it is now.
I am not sure whether that old TT_SEQUENCE code is supposed to be reachable (or present) at all. I would like to know an exact crash case that ddf109c3 guarded against.
Testing on commit d97574 , the most recent one it appears on.
pdf: pdf.c:4495: parse_pagenode: Assertion `entry->token_type == (HTokenType)TT_SEQUENCE' failed.Program received signal SIGABRT, Aborted.
(gdb) bt#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49#1 0x00007ffff7da2546 in __GI_abort () at abort.c:79#2 0x00007ffff7da242f in __assert_fail_base (fmt=0x7ffff7f18df8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x5555555700c0 "entry->token_type == (HTokenType)TT_SEQUENCE", file=0x55555556b010 "pdf.c", line=4495, function=<optimized out>) at assert.c:92#3 0x00007ffff7db1222 in __GI___assert_fail (assertion=0x5555555700c0 "entry->token_type == (HTokenType)TT_SEQUENCE", file=0x55555556b010 "pdf.c", line=4495, function=0x5555555710f8 <__PRETTY_FUNCTION__.6386> "parse_pagenode") at assert.c:101#4 0x00005555555668ac in parse_pagenode (aux=0x7fffffffde50, myNode=0x555555a46cf0, myRef=0x555555a293c0, myDict=0x555555a4ef18, parent_t=0x5555559d36e0, parent_n=0x7fffffffdea0, arena=0x555555a0e410) at pdf.c:4495#5 0x000055555556754c in parse_pagetree (aux=0x7fffffffde50, myNode=0x7fffffffdea0, myRef=0x5555559d36e0, myDict=0x555555a15548, parent_t=0x0, parent_n=0x0) at pdf.c:4706#6 0x00005555555677cd in parse_catalog (aux=0x7fffffffde50, root=0x5555559949e0) at pdf.c:4780#7 0x000055555556907a in parse_xrefs (aux=0x7fffffffde50) at pdf.c:5394#8 0x0000555555569482 in main (argc=1, argv=0x7fffffffe0e0) at pdf.c:5533
(gdb) p *entry$1 = {token_type = 67, {bytes = {token = 0x5555601236a8 "\004", len = 0}, sint = 93825172387496, uint = 93825172387496, dbl = 4.6355794391794503e-310, flt = 4.21431724e+19, seq = 0x5555601236a8, user = 0x5555601236a8}, index = 0, bit_length = 0, bit_offset = 0 '\000'}(gdb) p TT_Dict$2 = 67
At the moment I couldn't reproduce the issue on commit 005b97ec, but judging from past results, it was on line 4509. The corresponding line in pdf.c at that commit:
4507 if(contents->seq->used >= 2)4508 {4509 HParsedToken *res_strm = H_INDEX_TOKEN(contents, 1);4510 if (res_strm->token_type == TT_SEQUENCE) { // this seems like a big assumption4511 myNode->pn.textStream = res_strm;45124513 }4514 else4515 myNode->pn.textStream = NULL;4516 }