bugPSPP - Bugs: bug #45272, psppire crashes when exporting pdf

 
 

bug #45272: psppire crashes when exporting pdf

Submitted by:  Friedrich Beckmann <beckmanf>
Submitted on:  Sun 07 Jun 2015 06:32:16 PM UTC  
 
Category:  Output Driver Severity:  5 - Average
Status:  Fixed Assigned to:  None
Open/Closed:  Closed Release:  None
Effort:  0.00

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Wed 24 Jun 2015 10:36:02 PM UTC, comment #6:

The psppire crash when exporting pdf via gui is fixed with this commit:

http://git.savannah.gnu.org/cgit/pspp.git/commit/?id=2352789a3250e11e0f5d2fd35a319c8de502a926

The s390x regression failure is not related to that problem. The s390x regression failure is fixed with:

http://git.savannah.gnu.org/cgit/pspp.git/commit/?id=5520a0b23027ab60ed0b52a7d3841101b1ae68f3

Friedrich Beckmann <beckmanf>
Project Member
Mon 22 Jun 2015 03:45:34 PM UTC, comment #5:

The assertion crash is also reproducible on debian unstable with the current master branch and the syntax file crash.sps mentioned below. Currently only psppire crashes, but pspp has a different pdf output when called with

pspp -o chart.pdf crash.sps

because the commands are not repeated. Therefore, the page breaking is different and crash.sps does not result in an assertion with pspp.

An idea to fix the bug is described here

http://lists.gnu.org/archive/html/pspp-dev/2015-06/msg00064.html

waiting for the result on s390

Friedrich Beckmann <beckmanf>
Project Member
Mon 22 Jun 2015 04:15:14 AM UTC, comment #4:

I looked into this problem, so here is some analysis but not the fix yet...

The problem is related to a page break and a text/table which does not render with a progress in y direction as Ben mentioned below. In the file "charts.sps" is a part

======
frequencies
/variables = fred
/format=notable
/histogram=normal.

frequencies
/variables = pos neg posneg bigavgsmallvar bigavgbigvar smallavgbigvar smallavgsmallvar small uni
/format=notable
/histogram=normal.
==========

psppire runs without assertion when I remove the empty line between the frequencies statements. With the empty line, the first frequency statement is rendered, then the table, then the chart. After the chart the empty line is rendered. I added some printfs to the code and the output looks like this:

....
xr_driver_output_item item 0x7f8529718790
xr_render_output_item - item text, y: 788366
xr_render_text item: 0x7f8529718790, type: 5, y: 788366
xr_create_text_renderer y: 788366, text

xr_render_table item: 0x7f85297a4550, y: 788366
render_page_create
xr_measure_cell_width min: 0, max: 0
accumulate_row_widths axis 0 with 1 entries
cp[0] = 0
cp[1] = 0
accumulate_row_widths axis 1 with 1 entries
cp[0] = 0
cp[1] = 0
xr_driver_run_fsm
render_break_has_next axis: 0 return 0
render_break_has_next axis: 0 return 1
render_break_next axis: 0, size: 535833
render_break_has_next axis: 0 return 1
render_break_has_next axis: 1 return 1
render_pager_has_next true
render_pager_draw_next space: -13653
render_break_has_next axis: 1 return 1
render_pager_has_next true
render_break_next axis: 1, size: -13653
render_break_has_next axis: 1 return 1
xr_table_render y: 802019, length: 788366, used 0
xr_driver_need_new_page: fsm 0x7f8529798240
xr_driver_next_page
xr_driver_run_fsm
render_break_has_next axis: 1 return 1
render_pager_has_next true
render_pager_draw_next space: 788366
render_break_has_next axis: 1 return 1
render_pager_has_next true
render_break_next axis: 1, size: 788366
render_break_has_next axis: 1 return 1
render_page_draw
render_page_draw_cells
render_cell
render_pager_draw_next ofs(v): 0
render_break_has_next axis: 1 return 0
render_break_has_next axis: 0 return 0
render_pager_has_next false
xr_table_render y: 0, length: 788366, used 0
Assertion failed: (xr->y > 0), function xr_table_render, file ../pspp/src/output/cairo.c, line 1504.
Abort trap: 6
friedrismacbook:build fritz$

=======
So y is at 788366, while the page has length 788366. In xr_create_text_renderer, the string is printed (you see the line break). The render_page_create measures zero width and length if I interpret this right. Then render_pager_draw_next is started with a space of -13653 (I think this is one line). Then an empty page is generated, but in the new draw attempt the result of the drawing uses 0 space in y direction. This is the reason for the assert.

Friedrich Beckmann <beckmanf>
Project Member
Sun 21 Jun 2015 05:43:23 AM UTC, comment #3:

This bug might be related to the failed tests on s390 for the 0.8.5 release:

https://buildd.debian.org/status/fetch.php?pkg=pspp&arch=s390x&ver=0.8.5-1&stamp=1434844261

4 graph tests fail due to assertions. The tests render pdf and the assertion is the same as for psppire on macos.

482. graph.at:81: testing GRAPH missing values don't crash ...
./graph.at:98: pspp -o pspp.pdf scatter.sps
--- /dev/null 2011-03-04 11:53:52.000000000 +0000
+++ /«PKGBUILDDIR»/tests/testsuite.dir/at-groups/482/stderr 2015-06-20 23:49:44.636369854 +0000
@@ -0,0 +1,16 @@
+pspp: src/output/cairo.c:1494: xr_table_render: Assertion `xr->y > 0' failed.

Friedrich Beckmann <beckmanf>
Project Member
Sun 14 Jun 2015 09:38:20 PM UTC, comment #2:

This will probably require some debugging on the system where it's happening, so let me explain the context.

The function in question is a loop that is trying to draw as much of a table as can fit on the current page. It loops over the table as long as some of it is still yet to be drawn. The assertion that fails is one that makes sure that we're making progress. The logic is this: if we're in the middle of a page and we didn't make any progress in the last call to render_pager_draw_next() (that is, if it returned false, indicating that there wasn't room on the page to draw anything more), then that's OK, because it can just return "true" and the caller will move on to another page and try again. But if we're at the top of a page and we can't draw anything, then we'll never succeed at it since the next page is going have the same amount of space and we'd just loop forever. That's not supposed to happen, because we've calculated how to render the table on the basis of the size of a page, size of the fonts, and so on.

Does that give enough context to be able to look further into this?

If you find a way to reproduce this on GNU/Linux then I'll gladly fix it myself.

Ben Pfaff <blp>
Project Administrator
Mon 08 Jun 2015 01:39:17 PM UTC, comment #1:

The gdb backtrace is

psppire: ../pspp/src/output/cairo.c:1490: xr_table_render: Zusicherung »xr->y > 0« nicht erfüllt.

Program received signal SIGABRT, Aborted.
0x00007ffff3f0c165 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64 ../nptl/sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht gefunden.
(gdb) backtrace
#0 0x00007ffff3f0c165 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00007ffff3f0f3e0 in *__GI_abort () at abort.c:92
#2 0x00007ffff3f05311 in *__GI___assert_fail (assertion=assertion@entry=0x7ffff7bbfacc "xr->y > 0",
file=<optimized out>, file@entry=0x7ffff7bbfa9d "../pspp/src/output/cairo.c", line=line@entry=1490,
function=function@entry=0x7ffff7bbfde0 "xr_table_render") at assert.c:81
#3 0x00007ffff7ba77e5 in xr_table_render (fsm=<optimized out>, xr=<optimized out>) at ../pspp/src/output/cairo.c:1490
#4 xr_table_render (fsm=0x12743f0, xr=0x1235d40) at ../pspp/src/output/cairo.c:1479
#5 0x00007ffff7ba68a8 in xr_driver_run_fsm (xr=0x1235d40) at ../pspp/src/output/cairo.c:628
#6 0x00007ffff7ba854b in xr_submit (driver=0x1235d40, output_item=0xe3a4a0) at ../pspp/src/output/cairo.c:555
#7 0x000000000046ada8 in psppire_output_view_export (view=0xce54e0, options=<optimized out>)
at ../pspp/src/ui/gui/psppire-output-view.c:760
#8 0x000000000046b19e in export_output (window=<optimized out>, options=<optimized out>, format=<optimized out>)
at ../pspp/src/ui/gui/psppire-output-window.c:219
#9 0x000000000046b5b2 in psppire_output_window_export (window=0x83b1f0) at ../pspp/src/ui/gui/psppire-output-window.c:433
#10 0x00007ffff550b6e0 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0

Friedrich Beckmann <beckmanf>
Project Member
Sun 07 Jun 2015 06:32:16 PM UTC, original submission:

psppire 0.8.4 in the current macports osx version crashes when doing the following steps.

1. Open the attached charts.sps file
2. Execute the file
3. Go to the output window
4. Export the output window content as pdf

psppire crashes with

friedrismacbook:build fritz$ psppire
Assertion failed: (xr->y > 0), function xr_table_render, file src/output/cairo.c, line 1493.
Abort trap: 6
friedrismacbook:build fritz$

Also the current gtk3 branch crashes. When creating the pdf via

pspp --output=test.pdf crash.sps

then it works. The problem only occurs in psppire.

Friedrich

Friedrich Beckmann <beckmanf>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #34172:  crash.sps added by beckmanf (973B - application/octet-stream)
file #34173:  test.pdf added by beckmanf (92KiB - application/pdf)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by blp (Posted a comment)
  • -email is unavailable- added by beckmanf (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-06-24 beckmanf StatusNone => Fixed
        Open/ClosedOpen => Closed
        Summarypsppire / pspp crashes when exporting pdf => psppire crashes when exporting pdf
    2015-06-21 beckmanf CategoryGraphical User Interface => Output Driver
        Summarypsppire crashes when exporting pdf => psppire / pspp crashes when exporting pdf
    2015-06-07 beckmanf Attached File- => Added crash.sps, #34172
        Attached File- => Added test.pdf, #34173

    Back to the top


    Powered by Savane 3.4