Hmm. I don't think that's it. Here's the diff (texlive-base vs copy from evince):

[spot@dhcp1-67 texlive-base]$ diff -u texlive-base-20180414/source/texk/web2c/synctexdir/synctex_parser.c synctex_parser.c 
--- texlive-base-20180414/source/texk/web2c/synctexdir/synctex_parser.c	2017-10-31 07:50:59.000000000 -0400
+++ synctex_parser.c	2019-03-14 10:26:33.084246280 -0400
@@ -83,6 +83,11 @@
  *  First level objects are sheets and forms, containing boxes, glues, kerns...
  *  The third tree allows to browse leaves according to tag and line.
  */
+/* Declare _GNU_SOURCE for accessing vasprintf. For MSC compiler, vasprintf is
+ * defined in this file
+ */
+#define _GNU_SOURCE
+
 #   if defined(SYNCTEX_USE_LOCAL_HEADER)
 #       include "synctex_parser_local.h"
 #   else
@@ -262,6 +267,8 @@
 #       pragma mark Abstract OBJECTS and METHODS
 #   endif
 
+void synctex_node_free(synctex_node_p node);
+
 /**
  *  \def SYNCTEX_MSG_SEND
  *  \brief Takes care of sending the given message if possible.
@@ -533,6 +540,10 @@
     synctex_io_mode_t io_mode;
 } synctex_open_s;
 
+void synctex_reader_free(synctex_reader_p reader);
+synctex_reader_p synctex_reader_init_with_output_file(synctex_reader_p reader, const char * output, const char * build_directory);
+synctex_node_p _synctex_node_next(synctex_node_p node);
+
 /*	This functions opens the file at the "output" given location.
  *  It manages the problem of quoted filenames that appear with pdftex and filenames containing the space character.
  *  In TeXLive 2008, the synctex file created with pdftex did contain unexpected quotes.
@@ -747,7 +758,6 @@
             (char *)_synctex_malloc(reader->size+1); /*  one more character for null termination */
         if (NULL == reader->start) {
             _synctex_error("!  malloc error in synctex_reader_init_with_output_file.");
-        bailey:
 #ifdef SYNCTEX_DEBUG
             return reader;
 #else
@@ -5452,7 +5462,6 @@
 #       pragma mark + SCAN KERN
 #   endif
             ns = _synctex_parse_new_kern(scanner);
-        continue_scan:
             if (ns.status == SYNCTEX_STATUS_OK) {
                 if (child) {
                     _synctex_node_set_sibling(child,ns.node);
@@ -6023,7 +6032,6 @@
     if ((scanner->reader = synctex_reader_init_with_output_file(scanner->reader, output, build_directory))) {
         return parse? synctex_scanner_parse(scanner):scanner;
     }
-    _synctex_error("No file?");
     return NULL;
 }
 
*****

These changes correspond exactly to:

https://gitlab.gnome.org/GNOME/evince/commit/dab0dc31dba530b7c5d92122cd2047e0f3f97452
https://gitlab.gnome.org/GNOME/evince/commit/678410e81d0c889f4db4e995ca451ed62b8a2eee
https://gitlab.gnome.org/GNOME/evince/commit/90155d61c403985542273ac1496159bebcbec50c
https://gitlab.gnome.org/GNOME/evince/commit/e16ce591b290b044fa2d5073cc1151d036dcc047

I don't think any of those changes would have an effect on the issue you're seeing here. Can you share a reproducer case without evince?

This is the difference

- https://gitlab.gnome.org/GNOME/evince/blob/master/cut-n-paste/synctex/synctex_parser.c#L6025: 

    if ((scanner->reader = synctex_reader_init_with_output_file(scanner->reader, output, build_directory))) {
        return parse? synctex_scanner_parse(scanner):scanner;
    }
    return NULL;

- /usr/src/debug/texlive-base-20180414-30.fc29.x86_64/source/texk/web2c/synctexdir/synctex_parser.c :

6023     if ((scanner->reader = synctex_reader_init_with_output_file(scanner->reader, output, build_directory))) {•
6024         return parse? synctex_scanner_parse(scanner):scanner;•
6025     }•
6026     _synctex_error("No file?");•
6027     return NULL;•

That one error was removed in:
https://gitlab.gnome.org/GNOME/evince/commit/678410e81d0c889f4db4e995ca451ed62b8a2eee

Yes, but it was removed from evince with this comment:

"Evince deals with a multiple users and documents. It is natural
that many (if not most) of them will not have a SyncTeX
counterpart." 

It does not seem like that would be true of direct synctex calls...

(In reply to Tom "spot" Callaway from comment #3)
> Yes, but it was removed from evince with this comment:
> 
> "Evince deals with a multiple users and documents. It is natural
> that many (if not most) of them will not have a SyncTeX
> counterpart." 
> 
> It does not seem like that would be true of direct synctex calls...

That really isn't great API though, throwing warnings instead of letting
the caller do it. So what's the fix? Either an API change to return that
error along with the result, remove the error message and let the caller
guess what the error was, something else?

I'd be happy with evince being allowed to use its own copy of that library,
so that it doesn't throw errors for each PDF file opened, if that's an option.

Went back and forth on this one, but I decided to apply that change. The likelyhood that anyone will have an issue from that error check being silenced seems really low.

texlive-base-20180414-35.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-957aa2f6d7

texlive-base-20180414-35.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-2da61cfbfc

Works after testing locally. Thanks!

texlive-base-20180414-35.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-2da61cfbfc

texlive-base-20180414-35.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-957aa2f6d7

texlive-base-20180414-35.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.

texlive-base-20180414-35.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.