Reusing faup_handler_t instance is unsafe

[jdiner]

Reusing an instance of faup_handler_t will occasionally cause a segfault. Specifically, using an instance faup_handler_t to parse two URLs, one after another (not simultaneously). In my tests, this happens as frequently as once every 100 URLs parsed or as infrequently as once every 100K URLs parsed. But it always happens eventually.

The segfault always occurs in the TLD code. Here are two example backtraces from gdb, showing just the stack frames within libfaup:

#0 faup_tld_tree_tld_exists (Tree=, tld=, tld_len=) at /home/jdiner/projectx/src/libfaup/src/lib/tld-tree.c:295 #1 faup_tld_tree_extract (fh=, tld_tree=) at /home/jdiner/projectx/src/libfaup/src/lib/tld-tree.c:406 #2 0x000000000065c9cf in faup_decode (fh=0x7fb7e4070250, url=0x7fb7e4070f98 "jonbird.a4f96b687afedf2cc04075f58c4b31b93.profile.msp50.cloudfront.net", url_len=) at /home/jdiner/projectx/src/libfaup/src/lib/decode.c:228 ...

#0 faup_tld_tree_tld_exists (Tree=, tld=, tld_len=) at /home/jdiner/projectx/src/libfaup/src/lib/tld-tree.c:295 #1 faup_tld_tree_extract (fh=, tld_tree=) at /home/jdiner/projectx/src/libfaup/src/lib/tld-tree.c:406 #2 0x000000000065c9cf in faup_decode (fh=0x7ff800033eb0, url=0x7ff800033f88 "jonbird.0067-0-ams3095387e7bb06d27e2c6e6134b6482f6ddf4f5cda8.beacon.rum.dynapis.info", url_len=) at /home/jdiner/projectx/src/libfaup/src/lib/decode.c:228 ...

My guess is that there is some lingering state in the faup_handler_t instance that can occasionally cause parsing of a second URL to crash. I've worked around this by always allocating a new instance of faup_handler_t for each URL to be parsed. But this workaround is inefficient.

[stricaud]

Good catch! Will work on this, and provide a strong test to make sure we are good there.