[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [okular] [Bug 383915] Okular crashes with a segfault on reload for some synctex files
From:       Henrik Fehlauer <bugzilla_noreply () kde ! org>
Date:       2017-11-30 23:29:45
Message-ID: bug-383915-17878-1DfTHYW2VV () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=383915

--- Comment #20 from Henrik Fehlauer <rkflx@lab12.net> ---
Thanks for testing, your collection sounds impressive! You should run your
script regularly and report any new problems ;)

As for Okular, we (as in whoever contributes this) should extend
https://phabricator.kde.org/source/okular/browse/master/autotests/parttest.cpp;069a18b041ce3615ac9c6546c57399fe61481dc8$183
 to also cover broken documents. Apart from that, it's not really Okular's \
job to test synctex itself.

There is also <https://github.com/jlaurens/synctex/tree/2017/synctex test
files>, but this is nearly unusable without any buildsystem/testrunner. I
wonder if upstream is running all those test manually?

> Are you sure, this is not an expected behavior for old synctex files?
Well, screaming "! Error" and "ignoring records" is not something I would
expect ;) It was my first guess too yesterday, but looking at the upstream
commit you'll see that this line was there before (but commented out), it \
was only moved around and set active by default. This means the format \
errors could have been there all along. Are they going away if you \
recompile those old documents? Still, it looks like broken backwards \
compatibility.

Anyway, the only way to know for sure is to ask upstream, because I don't \
know a thing about this and also I have no access to the tex source to \
create the synctex file in question (with an older texlive version?) in the \
first place… Worst that could happen is a WONTFIX, best a patch. Just try \
it, I'd say.


> Okular could just call the synctex command line tool
Interesting, might be worth thinking about. However, I'm not yet convinced
switching from a C API (with type checking and only breaking at compile \
time, i.e. before reaching users) to a Bash API (passing strings over pipes \
and runtime version checks breaking on user's machines) is a good idea.

> If the synctex cmdline tool crashes, it does not affect okular
As you noted, for exploits this point is irrelevant. For crashing in \
general, decoupling is only worth the effort if it crashes very often, but \
again, then the crash should be fixed in the first place as we have access \
to the source.

> After the first shift-click, the user could be asked for confirmation
Not sure about this one. I think this approach has been shown to fail where \
it is needed most: Non-technical users. For all others it is just an \
annoyance. Would you like Gwenview to ask whether you trust a JPG? (We have \
dozens of duplicate EXIV crasher bugs, but only two for synctex.)

> Okular would not depend on synctex.
Could also be achieved by runtime-loading synctex support as a plugin?

> Delaying to load the synctex file until the first shift-click is of \
> course also an option if synctex is used as library.
This is an excellent idea! If only I had more time to work on such \
things…

-- 
You are receiving this mail because:
You are watching all bug changes.=


[prev in list] [next in list] [prev in thread] [next in thread]