Log in / Register

Forum › Bugs

Still bus errors on xserve running Leopard Server

peter-de-berdt
Given the great comments on PrinceXML all over the Net (and granted, they are true) I decided to evaluate it for a RoR application we're developing.

Using the blog post at that google gives a top result when searching for "princexml rails" everything was up and working fine on both Leopard client, Tiger client and a Ubuntu Dapper Drake box (all using the latest release). The last test was a production xserve 2.8 Ghz Quad-Core Intel Xeon with 2 GB of RAM running Leopard Server 10.5.1.

On that machine (brand new and only running this test application), the same application can't produce PDFs, it bombs with:
*** Mercury runtime: caught bus error ***
cause: non-existent physical address
address involved: 0x0
This may have been caused by a stack overflow, due to unbounded
recursion.
exiting from signal handler


Basically the script just runs the following command:
/usr/local/bin/prince --input=html --server --log=/var/rails/app/releases/20080201185556/
config/../log/prince.log  -s /var/rails/app/releases/20080201185556/
config/../app/views/prints/stylesheets/document.css  --silent - -o - <html is inserted here>
and sends the data it receives through the pipe back to the user as a downloadable file.

What makes it even weirder, is that running it under a single mongrel web server with only the prince classes parsing the exact same html, it runs fine... for a while.

Parsing the file not using a pipe (just writing the html to disk, then running it through a command line call and reading the resulting pdf back in) does work, but it's very inefficient.

One extra note: the html is XHTML 1.1 valid, not using any special CSS markup or font rendering. Permissions on the server are not the problem either.
mikeday
Fine for a while? So does it work for a while and then start crashing? What happens if you run it from the command-line on that machine, does it only fail when run from Ruby/the web server?
peter-de-berdt
In my original post, you could see we did try the command line and that works, but it does put a lot of extra load on the application (writing the html to disk, parsing it through the command line, reading the resulting file back in and serve that to the client). It's extremely inefficient.

Further testing on a Mac Pro with the same specs and OS resulted in the same problem. It's clearly OS-related and bus errors leave little to the imagination.

On a single mongrel just accepting the html (posted over localhost to the pdf-generating mongrel), it runs fine for about 10 pdfs, then it fails with bus errors. In an existing application (where we factored out PDF:writer to see if we could use PrinceXML to allow our customers to make their own print layouts easily), we get bus errors from the first PDF (with exactly the same HTML and stylesheets and classes).

Again, only Leopard server and Ruby+Mongrel (preferred rails setup) exhibit the problem. Those are the only common elements between the machines. We're currently looking into wrapping the pdf generation in a small python application, which will immediately determine if it's Ruby or Mongrel related. Should help us pin down the problem, but we'd still like to avoid having to do it that way and use Ruby directly if possible. I wish it were easier to reproduce than this, but it isn't.

Our customerbase is largely Mac-based, so we can expect most of them to demand installation on a Leopard Server configuration.
mikeday
What if you run it from the command-line with redirection, eg. specify "-" as the input and output and redirect standard input, like this:
/usr/local/bin/prince --input=html --server --log=/var/rails/app/releases/20080201185556/
config/../log/prince.log  -s /var/rails/app/releases/20080201185556/
config/../app/views/prints/stylesheets/document.css  --silent - -o - < input.html > output.pdf

However, if it works for a while and then fails that sounds like something in the environment is changing, as Prince doesn't update any files and should either always work or always fail.