View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005517 | Scribus | Import / Export | public | 2007-04-04 17:50 | 2007-11-28 10:46 |
| Reporter | dhlocker | Assigned To | jghali | ||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | closed | Resolution | duplicate | ||
| OS | Solaris 10, Win XP | ||||
| Product Version | 1.3.3.8 | ||||
| Summary | 0005517: Crash when exporting PDF (invalid memory reference) | ||||
| Description | (see also 005490) 1.3.3.9cvs from a week or so ago on a Sun workstation and 1.3.3.8 here at work. I have exactly one page that causes my problem. Looks like a memory allocation issue; a little gdb work last night narrowed down locality to ScImage::ImageToTxt, invoked as img.ImageToTxt at line 5328 in pdflib.cpp. Apparently violates mem inside inner xi loop. One machine is Sun Ultra 20M2 w/ Solaris 10, 3G RAM; Windoze machine is Dell Optiplex 170L Win XP, 2G RAM | ||||
| Steps To Reproduce | export attached file. | ||||
| Additional Information | A little gdb work last night narrowed down locality to ScImage::ImageToTxt, invoked as img.ImageToTxt at line 5328 in pdflib.cpp. Apparently violates mem inside inner xi loop. | ||||
| Tags | No tags attached. | ||||
| Patch | |||||
|
2007-04-04 17:50
|
|
|
|
Would you be able to attach the sla file and all images included to the bug? or if its too big, put it on a server somewhere? We need to be able to reproduce it ourselves to test and confirm any fix is correct. Thanks. |
|
|
Oops. Attached wrong file. Two times!! "This time f'r sure." |
|
2007-04-04 18:16
|
|
|
2007-04-04 18:36
|
|
|
|
That should be all. Thank you for a _wonderful_ product and the gracious support. |
|
|
I can export it ok here.. core duo, 2gb ram, gentoo linux, 1.3.3.9cvs. Are you able to try with current 1339cvs? I ended up producing a 200mb pdf .. wow. |
|
|
Of course, Solaris controls the memory differently and might be picking up a bug.. getting some others to test it too. |
|
|
Well that page is finalised and I need to get this to the printer this week. Would someone be willing to put the pdf out somewhere that I could grab it? After work today, I'll download the latest in the cvs tree and build again, but I'd like a backup strategy if possible. TIA, Donald. |
|
|
We can certainly export the PDF for you. Please let us know if the current CVS version doesnt work for you so we can do that. |
|
|
ah here it is anyway.. please proof it.. i dont know if there were font substitutions in place when i exported. http://docs.scribus.net/temp/encore07Cover.pdf.bz2 |
|
|
Anybody tried running the export under valgrind to see what it has to say? It's great at catching those works-but-badly-wrong issues. |
|
|
got the latest 1.3.3.9cvs last night and had same issue. Couldn't actually trace the point at which the exception occurred, since even with no -O at all, the for loop in ScImage::ImageToTxt seems to have been optimised out of existence. |
|
|
And with -O0 -g3 ? (no optimisation, level 3 debugging info) |
|
|
I guess that'll be tonight's task. |
|
|
Any results there with those settings? |
|
|
Sorry, no results yet. Too busy producing the book just now. Final copy due about 24 hrs from now. I did compile it and it did crash when I ran it, but I decided I _really_ need to get the product done first. Thank you. |
|
|
1.3.3.9cvs of 10 April. Traced into qstring.h:1045 At this point, s2 is "\nendstream\nendobj\n" and all looks OK. I believe this is at the very end of the creation of the pdf for this particular page. tmp is [apparently] created correctly at line 1044, then tmp += QString::fromAscii(s2); has an issue. I just managed to stepi over the exception by a few thousand instructions, and need to get some sleep. So I'll try again in the next few days. |
|
|
Still not finding the _real_ problem. The memory error is in the qt libs or libstdc++. #0 0xfdfc7075 in __cxa_throw () from /opt/csw/lib/i386/libstdc++.so.6 0000001 0xfdfc733c in operator new () 0000002 0xfdfc73fc in operator new[] () from /opt/csw/lib/i386/libstdc++.so.6 0000003 0xfe724f0a in QString::setLength () from /opt/csw/kde-gcc/lib/libqt-mt.so.3 0000004 0xfe725074 in QString::subat () from /opt/csw/kde-gcc/lib/libqt-mt.so.3 0000005 0x0874db34 in QString::ref (this=0x80414d0, i=201326592) at /opt/csw/kde-gcc/include/qstring.h:648 Which version of Qt and libstdc++ is the 1.3.3.9cvs built against? I'm using Qt 3.3.4 and libstdc++ 6.0.3 (which are the latest on blastwave.org) I just downloaded qt 4.2.3 source to build locally. Would this be wise or is there a "better" qt (and/or libstdc++) to use? |
|
|
Qt 4.x is not usable until we release Scribus 1.3.5. |
|
|
I think the cause of the crash is simply ImgStr.reserve(3 * h * w) failling to allocate memory. |
|
|
It may well be that as encoreFront.png is a 6762x10339 image and allocating a single block of 200Mb of memory may fail even on 3Gb machine depending on memory fragmentation and current virtual memory use. |
|
|
In fact in this case, it gonna be at least 400Mb as QString uses at least 2 bytes per channel |
|
|
At this time, I'm going to leave it alone. By reducing resolution and switching it greyscale (decided for cost purposes to print in monochrome :) I was able to do this all myself. The only issue remaining, as far as I'm concerned, is the unclean way that the memory allocation failure was handled. But it looks like this is a Qt issue, not Scribus. Keep up the good work. Donald. |
|
|
Duplicate of 0004189 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2007-04-04 17:50 | dhlocker | New Issue | |
| 2007-04-04 17:50 | dhlocker | File Added: encore07Cover.pdf | |
| 2007-04-04 17:54 | cbradney | Note Added: 0015733 | |
| 2007-04-04 18:16 | dhlocker | Note Added: 0015734 | |
| 2007-04-04 18:16 | dhlocker | File Added: encore07Cover.sla | |
| 2007-04-04 18:36 | dhlocker | File Added: encoreFront.png | |
| 2007-04-04 18:37 | dhlocker | Note Added: 0015735 | |
| 2007-04-04 20:34 | cbradney | Note Added: 0015737 | |
| 2007-04-04 20:37 | cbradney | Note Added: 0015738 | |
| 2007-04-09 13:14 | dhlocker | Note Added: 0015823 | |
| 2007-04-09 13:16 | cbradney | Note Added: 0015824 | |
| 2007-04-09 13:27 | cbradney | Note Added: 0015825 | |
| 2007-04-10 03:25 |
|
Note Added: 0015841 | |
| 2007-04-10 13:59 | dhlocker | Note Added: 0015846 | |
| 2007-04-10 14:25 | cbradney | Note Added: 0015847 | |
| 2007-04-10 15:38 | dhlocker | Note Added: 0015849 | |
| 2007-04-12 07:38 | cbradney | Note Added: 0015877 | |
| 2007-04-12 11:11 | dhlocker | Note Added: 0015878 | |
| 2007-04-17 02:54 | dhlocker | Note Added: 0015928 | |
| 2007-04-26 04:47 | dhlocker | Note Added: 0016021 | |
| 2007-04-26 11:07 | cbradney | Note Added: 0016022 | |
| 2007-04-26 16:21 | jghali | Note Added: 0016027 | |
| 2007-04-26 16:30 | jghali | Note Added: 0016028 | |
| 2007-04-26 16:32 | jghali | Note Added: 0016029 | |
| 2007-04-26 19:30 |
|
Relationship added | related to 0002438 |
| 2007-05-01 22:44 | dhlocker | Note Added: 0016067 | |
| 2007-11-28 10:46 | jghali | Relationship added | duplicate of 0004189 |
| 2007-11-28 10:46 | jghali | Duplicate ID | 0 => 4189 |
| 2007-11-28 10:46 | jghali | Status | new => resolved |
| 2007-11-28 10:46 | jghali | Resolution | open => duplicate |
| 2007-11-28 10:46 | jghali | Assigned To | => jghali |
| 2007-11-28 10:46 | jghali | Note Added: 0018026 | |
| 2007-11-28 10:46 | jghali | Status | resolved => closed |
