Segmentation fault on render large tables

[GoogleCodeExporter]

Hello!

I'm trying to render a large pdf (around 16 pages  with large tables) and I get 
a segmentation fault.

This is what apache log shows:

 [Tue Feb 07 11:56:22 2012] [notice] child pid 15870 exit signal Segmentation fault (11)
*** glibc detected *** /usr/sbin/apache2: corrupted double-linked list: 
0xbfec7b90 ***
[Tue Feb 07 11:56:22 2012] [notice] child pid 15870 exit signal Segmentation 
fault (11)
*** glibc detected *** /usr/sbin/apache2: corrupted double-linked list: 
0xbfec7b90 ***
....

I've tried the comment 11 and 9, but nothing happens...

http://code.google.com/p/dompdf/issues/detail?id=37#c24

I've reproduced this issue on two environment

Enviroment 1:

DOMPDF: 0.6 beta 2
PHP: 5.3.2 
UBUNTU: 10.04 

Enviroment 2:
DOMPDF: 0.6 beta 2
PHP: 5.3.6 
UBUNTU: 11.10

You can see the HTML code and configuration in the attachment files

Any ideas?

Thanks in advance

Original issue reported on code.google.com by albertoasuero@gmail.com on 7 Feb 2012 at 11:21

Attachments:

• dompdf_config.custom.inc.php
• pdf_settlement_view.php

[GoogleCodeExporter]

It would help more to see the output from pdf_settlement_view.php (i.e. the 
actual HTML rendered by dompdf that results in a crash). Using what you have 
provided I am unable to reproduce your error (on php 5.3.5).

Original comment by eclecticgeek on 7 Feb 2012 at 10:45

[GoogleCodeExporter]

Here is the html

Original comment by albertoasuero@gmail.com on 8 Feb 2012 at 4:03

Attachments:

• settlement.html

[GoogleCodeExporter]

I got your document to work by adding the missing closing </tr> and by removing 
half the tables rows (5 pages), with the latest version from the SVN trunk. 
Dompdf is memory consuming when dealing with tables, this is something we are 
working on.
You could try to split the table in subtables or 50 rows.

Original comment by fabien.menager on 8 Feb 2012 at 9:13

[GoogleCodeExporter]

One way for you to be able to generate more lines is to reduce the DOM inside 
of the table, for example, the <strong> element can be avoided, by using a 
class for the cells you want to be bold, or by using something like this (if 
the cell is always the third in the rows) : 

#my_table td:nth-child(3) {
  font-weight: bold;
}

Note that this will work in the beta 3 we are planning to release this week or 
by using the latest code from the trunk. Generally, the fewer DOM elements 
there are, the less memory will be used by DOMPDF.

Original comment by fabien.menager on 8 Feb 2012 at 9:32

[GoogleCodeExporter]

Thank you very much!

I'm going to fix the missing closing <tr/> and optimizing the DOM.

I will test it with the code from the trunk (or the beta 3 if it's available) 
and I'll post my result.

Original comment by albertoasuero@gmail.com on 9 Feb 2012 at 8:38

[GoogleCodeExporter]

Original comment by eclecticgeek on 24 May 2013 at 3:00

• Added labels: Restrict-AddIssueComment-Commit