Getting a segfault when running samples for PHP wrapper

I'm trying to setup PDFNet to work with my PHP project. I've followed the steps in the Linux example at GitHub - PDFTron/PDFNetWrappers: Code repository for building different language bindings for PDFNetC. and everything seemed to work correctly.

vagrant@nxtboard:~/wrappers_build/PDFNetWrappers/Build$ sudo make install
[100%] Built target PDFNetPHP
Install the project...
-- Install configuration: ""
-- Installing: /home/vagrant/wrappers_build/PDFNetWrappers/PDFNetC/Lib/PDFNetPHP.php
-- Installing: /home/vagrant/wrappers_build/PDFNetWrappers/PDFNetC/Lib/PDFNetPHP_core.php
-- Installing: /home/vagrant/wrappers_build/PDFNetWrappers/PDFNetC/Lib/
-- Set runtime path of "/home/vagrant/wrappers_build/PDFNetWrappers/PDFNetC/Lib/" to ""
-- Installing: /usr/lib/php/20170718/

When I run php -i, I see that it's recognized the ini file I setup to load
Additional Modules

Module Name


vagrant@nxtboard:~/wrappers_build/PDFNetWrappers/Samples$ more /etc/php/7.2/cli/conf.d/20-pdfnet.ini

However, when I go to run the samples, I get the following:

vagrant@nxtboard:~/wrappers_build/PDFNetWrappers/Samples$ ./
AddImageTest running

PDFNet is running in demo mode.
Permission: write
Done. Result saved in addimage.pdf...
Segmentation fault (core dumped)

Any thoughts?

Could you provide your vagrant file? Or at least provide the box you used?

Can you provide the following info:

  1. swig.log
  2. swig.err.log
  3. CMakeFiles/CmakeOutput.log
  4. The printed terminal output when you run “cmake -D BUILD_PDFNetPHP=ON …”
    (Run: “cmake -D BUILD_PDFNetPHP=ON … >> output.log”)

Note: It would be best to clear all the binaries, so the log files generated above include the entire process.

I am using laravel/homestead (virtualbox, 6.4.0) which is Ubuntu 18.04. Linux nxtboard 4.15.0-38-generic #41-Ubuntu SMP Wed Oct 10 10:59:38 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Here are the requested log files. Let me know if you need more information.


CMakeOutput.log (29.1 KB)

output.log (652 Bytes)

swig.err.log (13.7 KB)

(Attachment swig.log is missing)

I don’t see any issues in the logs, so it appears to be a “regular” runtime issue.

Our SDK comes in 32 and 64 bit versions. You need to match your PHP version.

Once you have that matched, and you still get the crash, then do you get any additional diagnostic information?

I’m using the 64 bit version of PHP and when I followed the install instructions from your site, I downloaded the 64bit version of PDFTron as well.

Still getting the crash. Here is a debug file I generated using apport-bug. I’m not sure where else there would be other diagnostic info since it’s being run on the cli.

_usr_bin_php7.2.1000.crash (5.72 MB)

I tried the following, and it worked fine for me.

  1. Created vagrant box for “generic/ubuntu1804”, with a virtualbox 2CPU/8GB vm.
  2. installed the following dependencies: swig, cmake, g++, php7.2-cli, php7.2-dev
  3. Followed the exact instructions here:
  4. The sample did not run due to the following error (unrelated to PDFNet) =>“php dynamically loaded extensions aren’t enabled”
  5. So I ran “php --ini” to find the php.ini file being used, and changed “enable_dl=Off” to “enable_dl=On”
  6. Then re-ran the sample, and everything worked fine.

vagrant@ubuntu1804:~/wrappers_build/PDFNetWrappers/Samples/AddImageTest/PHP$ ./

PDFNet is running in demo mode.
Permission: write
Done. Result saved in addimage.pdf…


​Do the steps above work for you?

It did and I also figured out the problem I had was not setting the full path to the shared library in the ini file for PDFNet so that I didn’t have to enable the dynamic library setting. What’s odd about that to me is that if you look at how other ini files are setup, they don’t list the directory either.

What I had originally tried:


What worked:


However I have noticed that with running the full set of samples, I am still seeing seg faults for a number of other samples(even with enable_dl on and the removal of the ini file). Do you see this as well?

​Thank you for the update. Actually the team is aware that sometimes there is a segmentation fault, when the process is terminating.

Since it occurs while the process is shutting down, there is no known negative side effect, and we have customers currently using us in PHP7.

The team is looking into this issue. But in the meantime, you should be fine to continue with your evaluation/integration.

If you find this to actually cause you an issue, please let us know.

Hey there, I notice this is from June. But has the team narrowed down the segfault issue when exiting?
It returns a Segmentation fault only when the process hasn’t made any writes. But honestly I’m trying to find where the error is coming from so I can wrap it to throw a proper PHP exception. And at least know nothing has been written.

I believe the segfault on application termination is still there yes.

Since the application is terminating and all resources are being released anyway, could you elaborate on why you are trying to throw a proper exception?
If the app is terminating why is catching important?
Note, that a process cannot continue to run after a seg fault, the process needs to end, you are only supposed to get any last diagnostic info before allowing the process to terminate.