We have a web page for which always leads to a core dump with prince 9. We did not test this with prince 10 as we do not have that installed / licensed.

prince-9 -o latest.pdf "https://www.boerse-stuttgart.de/de/boersenportal/boersenwissen/buecherecke/grundlagen-anlagestrategien/?PDF_OMMIT_CODE=1" --ssl-blindly-trust-server --javascript --media=printpdf

The output on screen is as follows:

[fts@princexml1 pdfgen]$ ~/pdfgen/prince-9 -o share/caches/13877/pdfs/latest.pdf "https://www.boerse-stuttgart.de/de/boersenportal/boersenwissen/buecherecke/grundlagen-anlagestrategien/?PDF_OMMIT_CODE=1" --ssl-blindly-trust-server --javascript --media=printpdf
*** glibc detected *** /usr/lib/prince/bin/prince: free(): invalid pointer: 0x0000000013056420 ***
======= Backtrace: =========
/lib64/libc.so.6[0x2af7d6a6330f]
/lib64/libc.so.6(cfree+0x4b)[0x2af7d6a6376b]
/usr/lib/prince/bin/prince[0x86422d]
/usr/lib/prince/bin/prince[0x864290]
/usr/lib/prince/bin/prince[0x864290]
/usr/lib/prince/bin/prince[0x864290]
/usr/lib/prince/bin/prince[0x864290]
/usr/lib/prince/bin/prince[0x864290]
/usr/lib/prince/bin/prince[0x864290]
/usr/lib/prince/bin/prince[0x864290]
/usr/lib/prince/bin/prince[0x864290]
/usr/lib/prince/bin/prince[0x864290]
/usr/lib/prince/bin/prince[0x864290]
/usr/lib/prince/bin/prince[0x864290]
/usr/lib/prince/bin/prince[0x864290]
/usr/lib/prince/bin/prince[0x864290]
/usr/lib/prince/bin/prince[0x864290]
/usr/lib/prince/bin/prince[0x864290]
/usr/lib/prince/bin/prince[0x46c78e]
/usr/lib/prince/bin/prince[0xbc6940]
/usr/lib/prince/bin/prince[0xbdfee0]
/usr/lib/prince/bin/prince[0x406116]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x2af7d6a0e994]
/usr/lib/prince/bin/prince(realloc+0x211)[0x405e69]
======= Memory map: ========
00400000-00f08000 r-xp 00000000 08:02 622644                             /usr/lib/prince/bin/prince
01107000-01124000 rw-p 00b07000 08:02 622644                             /usr/lib/prince/bin/prince
01124000-0169e000 rw-p 01124000 00:00 0
1021a000-12379000 rw-p 1021a000 00:00 0
12379000-12382000 r--p 12379000 00:00 0
12382000-12389000 rw-p 12382000 00:00 0
12389000-1238a000 r--p 12389000 00:00 0
1238a000-12403000 rw-p 1238a000 00:00 0
12403000-1240c000 r--p 12403000 00:00 0
1240c000-12413000 rw-p 1240c000 00:00 0
12413000-12414000 r--p 12413000 00:00 0
12414000-13085000 rw-p 12414000 00:00 0
2af7d45bc000-2af7d45d8000 r-xp 00000000 08:02 163843                     /lib64/ld-2.5.so
2af7d45d8000-2af7d45db000 rw-p 2af7d45d8000 00:00 0
2af7d45db000-2af7d45de000 r--s 00000000 08:02 885424                     /var/cache/fontconfig/e3ead4b767b8819993a6fa3ae306afa9-x86-64.cache-2
2af7d45e2000-2af7d45e3000 rw-p 2af7d45e2000 00:00 0
2af7d45e3000-2af7d45f4000 r--s 00000000 08:04 4653320                    /home/fts/.fontconfig/73a61b34dd8ca4d8a159807604ab432f-x86-64.cache-2
2af7d47d7000-2af7d47d8000 r--p 0001b000 08:02 163843                     /lib64/ld-2.5.so
2af7d47d8000-2af7d47d9000 rw-p 0001c000 08:02 163843                     /lib64/ld-2.5.so
2af7d47d9000-2af7d47ef000 r-xp 00000000 08:02 163875                     /lib64/libpthread-2.5.so
2af7d47ef000-2af7d49ee000 ---p 00016000 08:02 163875                     /lib64/libpthread-2.5.so
2af7d49ee000-2af7d49ef000 r--p 00015000 08:02 163875                     /lib64/libpthread-2.5.so
2af7d49ef000-2af7d49f0000 rw-p 00016000 08:02 163875                     /lib64/libpthread-2.5.so
2af7d49f0000-2af7d49f4000 rw-p 2af7d49f0000 00:00 0
2af7d49f4000-2af7d4a17000 r-xp 00000000 08:02 440979                     /usr/lib64/libpng12.so.0.10.0
2af7d4a17000-2af7d4c17000 ---p 00023000 08:02 440979                     /usr/lib64/libpng12.so.0.10.0
2af7d4c17000-2af7d4c18000 rw-p 00023000 08:02 440979                     /usr/lib64/libpng12.so.0.10.0
2af7d4c18000-2af7d4c6f000 r-xp 00000000 08:02 440949                     /usr/lib64/libtiff.so.3.8.2
2af7d4c6f000-2af7d4e6f000 ---p 00057000 08:02 440949                     /usr/lib64/libtiff.so.3.8.2
2af7d4e6f000-2af7d4e72000 rw-p 00057000 08:02 440949                     /usr/lib64/libtiff.so.3.8.2
2af7d4e72000-2af7d4e73000 rw-p 2af7d4e72000 00:00 0
2af7d4e73000-2af7d4e94000 r-xp 00000000 08:02 440920                     /usr/lib64/libjpeg.so.62.0.0
2af7d4e94000-2af7d5093000 ---p 00021000 08:02 440920                     /usr/lib64/libjpeg.so.62.0.0
2af7d5093000-2af7d5094000 rw-p 00020000 08:02 440920                     /usr/lib64/libjpeg.so.62.0.0
2af7d5094000-2af7d50a8000 r-xp 00000000 08:02 432524                     /usr/lib64/libz.so.1.2.3
2af7d50a8000-2af7d52a7000 ---p 00014000 08:02 432524                     /usr/lib64/libz.so.1.2.3
2af7d52a7000-2af7d52a8000 rw-p 00013000 08:02 432524            Aborted (core dumped)

The core file I can send via email on request.

Thanks
Andy

It appears to work with Prince 10, and does not require disabling SSL security. Which platform are you running Prince on, and what is the output of "prince --version --debug"?

Prince is running on CentOS 5.5 (we'd like to move off it, but we still have customers on prince 6 which runs on the same hosts):

[fts@princexml1 pdfgen]$ prince --version --debug
(removed - output was for prince 6, not prince 9. See below for correct version output)

[fts@princexml1 pdfgen]$ cat /etc/redhat-release
CentOS release 5.5 (Final)

1. core.20291.gz‎ 664.1 kB ‎
   Core file for forum topic 3348

Edited 4 Apr 2016 by thecowster

Sorry, let me give you that again - this time for Prince9:

[fts@princexml1 pdfgen]$ prince-9 --version --debug
prince: debug: loading license: /usr/lib/prince/license/license.dat
Prince 9.0 rev 2
Copyright 2002-2013 YesLogic Pty. Ltd.
Server License
build-date: 2013-08-06
build-grade: asm_fast.gc

Could you try upgrading to Prince 9.0 rev 5?

I have reproduced the problem with 9.0 rev 2, but it appears to work fine in rev 4 and rev 5.

Mike, thanks for your fast response (as ever!)

Indeed 9.5 does resolve this issue, but while comparing some PDFs between 9.2 and 9.5 I found that two others now lead to a core dump in 9.5 (but work fine in 9.2)

Please try the attached html file "page.html", with the command:

prince-9.5 -o page.pdf page.html

1. page.html‎ 21.4 kB

Edited 5 Apr 2016 by thecowster

I think you missed the attachment.

The other failure only occurs when I provide the url to prince (along with --ssl-blindly-trust-server). If I download the page first, then call prince for the local html, it renders fine.

Here's how to reperoduce the second fail case:

prince-9.5 -o latest.pdf "https://amp.is-teledata.com/brownshipley/funds/research_note.html?PDF=1&&LANG=en&SID=6s34isu3j35b6qn071u2frcnk1&KBL_USER=45504793&KBL_AFFILIATE=7412&KBL_PROFILE=pt&ID_INSTRUMENT=21846340&FUND_TYPE=mStar&SELF_AUTH=1" --ssl-blindly-trust-server

Edited 5 Apr 2016 by thecowster

Sorry, I didn't realise that files are attached to individual posts. I have resolved the missing attachment now

Unfortunately I cannot reproduce these failures, it seems to successfully generate the PDF file with Prince 9.0 rev 5 on CentOS 5 (32-bit).

Would you be able to run with --debug and attach the log output from before it crashes? Also it might help to run "ldd /usr/lib/prince/bin/prince" so we can see if there are some different shared libraries in use. What version of curl is installed on the server?

Below is the debug output from the first fail case:

[fts@princexml1.test pdfgen]$ ~/pdfgen/prince-9.5 -o page.pdf page.html --ssl-blindly-trust-server --debug
prince: debug: loading license: /usr/local/lib/prince-9/license/license.dat
prince: /usr/local/lib/prince-9/license/license.dat: warning: inapplicable license
prince: loading style sheet: /usr/local/lib/prince-9/style/fonts.css
prince: debug: loaded resource: /usr/local/lib/prince-9/style/fonts.css
prince: debug: loaded resource: type: no
prince: Loading document...
prince: loading HTML5 input: page.html
prince: loading document: page.html
prince: debug: loaded resource: page.html
prince: debug: loaded resource: type: no

*** Mercury runtime: caught segmentation violation ***
cause: address not mapped to object
address involved: 0x505b
This may have been caused by a stack overflow, due to unbounded recursion.
exiting from signal handler
Segmentation fault (core dumped)

It seems that we're using a statically linked executable:

[fts@princexml1.test pdfgen]$ ldd /usr/local/lib/prince-9/bin/prince
        not a dynamic executable

(our "prince-9.5" file is a just sym-link to the above binary). Its also 16MB rather than 12MB (the size on disk of 9.2 when dynamically linked)

Curl got updated after the recent SSL scares, so I think its quite recent (but probably not related because we're using a statically linked binary):

[fts@princexml1.test pdfgen]$ curl --version
curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.2.3 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

Edited 5 Apr 2016 by thecowster

Ah, would it be possible to install the Prince RPM package for CentOS 5 instead, which is dynamically linked? If the RPM cannot be installed, it is possible to extract the files (using the cpio tool if I recall) and grab the dynamically linked Prince binary from it.

I'm discussing this with our internal administration team responsible for the system. I will update this topic as soon as Ihave an answer. (We have prince 9.2 and prince 6.5 also on that host; this could be a factor in why they chose to simply extract the tgz file)

[original comment removed]

We now have prince 9.5 installed and dynamically linked. The previously mentioned two failures no longer occur. I am now testing some other apps from our request logs.

Edited 7 Apr 2016 by thecowster

This one, which requires libtiff.so.3:

http://www.princexml.com/download/prince-9.0-5.centos52.i386.rpm

Mike, I am sorry but I edited my comment after I wrote it, as we finally got the rpm installed today.

9.5 looks to be working fine for us, and we have no any core dumps.

Our license restricts us from using 9.5. Perhaps we should continue this discussion by email, as its no longer so relavant for the rest of the community?

Sorry - my mistake. I think our license file is not installed in the new prince 9.5 folder. Will get our admins to correct that and get back to you.

[Correction]: Actually the license is already installed and everything is fine. It was the statically linked prince 9.5 that reported a bad license earlier in the week. I should have checked before submitting the last comment.

Edited 7 Apr 2016 by thecowster

This topic iis now resolved. Thanks Mike!