Release v1.14 - Githubissues

dannyedel commented 8 years ago

The number of changes (especially the Qt5 and Windows ports) justify releasing a new version.

I tested building on Debian myself, and I know from @projekter's #122 that it works on Windows.

@wwwdata can you verify this PR builds correctly on OSX? If I get your okay I'll release tomorrow.

Please note there is now a testsuite, and if you don't specify -DDownloadTestPDF=ON on the cmake command line, you need a working latex-beamer installation at build time.
If you want to build against Qt5, specify -DUseQtFive=ON at cmake time.

projekter commented 8 years ago

I ran the test suite. While all checks passed, there are several memory leaks. Maybe they are due to external libraries, but you might want to have a look at it.

wwwdata commented 8 years ago

was working fine on OSX 10.11.1 and the tests are working for me too

./testrunner                                                                                                                                            ✓  22:05:33
Running 3 test cases...

*** No errors detected

dannyedel commented 8 years ago

there are several memory leaks.

I tried to look at this document, but it's all very cryptic to me. From the plain memory layout I can't really tell anything (the only snippet that makes remotely sense to me is sRGB, which could be part of some image decoder memory segment)

If you could make the memory dumper display any kind of debugging information (such as object types, or a stacktrace from where the block was new'd from) I could try to fix it, but with this output I don't see anything.

But I'm sure (git grep confirms that) that I did never use the strings No copyr or sRGB bui anywhere in the sourcecode, so IMO this is likely to be an external library.

When I run the testrunner through valgrind, it reports a few cases of "possibly lost" memory, but these all are buried deep inside libglib or libgobject (dependencies of poppler), and the memory got allocated by calls directly from _dl_init (library load time, before my main() even starts). So I'm confident this is just some global state glib allocates and has nothing to do with me using the library wrong.

If you could make the program dump in a format similar to that, that shows where/when the memory in question got allocated, I think we can take a look. Otherwise I fear we're lost and have to live with it.

dannyedel commented 8 years ago

It seems there are no showstoppers, so I'll release v1.14.

dannyedel / dspdfviewer

Release v1.14 #123