View Issue Details

IDProjectCategoryView StatusLast Update
0008430ScribusUsabilitypublic2015-05-08 00:40
ReporterN7DR Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
Status newResolutionopen 
Platform64-bitOSLinux 
Product Version1.3.5 
Summary0008430: Provide detailed feedback as to what's wrong when crashing when opening document
DescriptionMy experience is that Scribus often crashes when trying to open a document that was created by an earlier version. When this happens, all that the user is told is "Scribus crashes due to signal 0000011".

The user has no way to start trying to figure out what Scribus is objecting to.

I think that some MUCH more informative text should be supplied, indicating where in the file Scribus was, and possibly what Scribus was trying to do when the crash occurred. That way, one can look at that part of the file with an editor and try to figure out how to fix the problem.

(I could argue that it should NEVER be possible to crash Scribus, but I suppose that's a philosophical issue and I don't want to get into it. In this request, I'm just asking to be told why a particular kind of crash is happening, or at the very least what in the file caused the crash.)
Steps To ReproduceOpening some files crash Scribus, opening others doesn't. If one tries to open one that *does* crash Scribus, then the crash occurs 100% of the time.
 
TagsNo tags attached.
Patch

Relationships

related to 0012679 closed [REQUEST] Useful if signal 11 and 6 could be more informative 
child of 0013050 new [Feature] Add optional info box in GUI for debug purposes and reporting more indepth errors 

Activities

cbradney

2009-09-14 22:11

administrator   ~0022487

Please provide sample docs that crash Scribus. Sometimes it will not be possible to find out why (via code)

2009-09-14 22:49

 

cover-1.sla (261,761 bytes)

2009-09-14 22:51

 

cover-1-page1.jpg (709,370 bytes)   
cover-1-page1.jpg (709,370 bytes)   

N7DR

2009-09-14 22:52

reporter   ~0022488

Attaching a sample that crashes on opening. I'll also upload the output document that an earlier version produced from this file.

I don't understand your comment about it not always being possible why a crash is occurring. You may want to elaborate privately, if you think it's important.

christoph_s

2009-09-15 05:01

developer   ~0022491

You mention Linux as your platform. Unfortunately, this info isn't suffcient. Information regarding your distro and its version number would certainly help.

No matter what distro you use, you can always start Scribus from the command line, and if you want to provide us the details of a crash, you can always build Scribus from source and create a version with debugging enabled.

And btw, the file you uploaded didn't crash at all here.

cbradney

2009-09-15 20:17

administrator   ~0022492

When Scribus crashes, it has not decided to do so, so therefore it may not be able to track what has gone wrong. Depending on how it was built (debug libraries etc) there may not even be any chance of getting any backtrace of what was going on anyway.

N7DR

2009-10-22 17:34

reporter   ~0022739

The issue here is nothing whatsoever to do with fixing a crash... I'm not reporting a crash that needs fixing. It's also nothing to do with backtraces. Nor to do with trying to debug the problem by using the command line.

This is a request that when Scribus does crash it should be more informative than simply telling the user that a crash occurred.

I write telecom software and this is the kind of thing we have to do all the time... in our case, whatever the input, the software MUST NOT crash, but MUST report an issue with malformed input. Like I said in the original request, the "MUST NOT crash" part is philosophical, and I don't care about (much) about the fact that Scribus can crash when it thinks there's a problem with the input, but the important point is that Scribus really should provide the user with details so that he can try to fix his file, rather than simply providing no useful information to the user when it does crash.

jghali

2009-10-22 17:52

administrator   ~0022740

>> the important point is that Scribus really should provide the user with details so that he can try to fix his file

In most case there is nothing to fix in the file itself. The crash is a bug, is of course unwanted and must be fixed. And until it's looked at and fixed, there is nothing which can be reported.

N7DR

2009-10-28 19:56

reporter   ~0022761

This request is obviously going nowhere :-(

Saying that "there is nothing to fix in the file itself" simply makes no sense whatsoever. If Scribus crashes when opening a file, how can the cause of the crash be anywhere other than in the process of parsing the file? (OK, maybe in theory it could be elsewhere, like a non-existent file; but in practice it is almost certain that the parser has stumbled somewhere.)

I truly don't understand the apparent reluctance to tell the user where the parser detected the problem. How can a crash without information ever be better for the user than a crash with information that the user can use to at least try to work around the crash?

Oh well; I guess I just don't understand the philosophy behind development for the desktop. I'll go away and do something more useful than trying to change your minds.

cbradney

2009-10-28 20:48

administrator   ~0022762

We develop Scribus in our spare time.. that might equate to 2-3 hours per day for 3-4 people at the most at this point. Sometimes it is higher, sometimes lower. We have not closed your issue so we will get to it, but that could literally be in 6m time.

As per the parser comment, in fact, the issue is more than likely in memory allocation or similar, rather than parser issues. The format has not changed that much.

N7DR

2009-10-28 21:28

reporter   ~0022763

I had misunderstood the earlier developer comments, then, for which I apologise.

I had interpreted them to mean "we aren't going to provide the requested feedback", since they seemed to contain lots of comments that didn't seem germane to the request and nothing that actually said "yes, we will do this".

cbradney

2009-10-28 23:12

administrator   ~0022764

We may not be able to get the requested feedback.. in some cases, the best we could do is produce a crash report, and not a report about the document. Right now, I would not think we know of a good way to get a good backtrace of a crash cross platform (or even at all).

Issue History

Date Modified Username Field Change
2009-09-14 20:55 N7DR New Issue
2009-09-14 22:11 cbradney Note Added: 0022487
2009-09-14 22:49 N7DR File Added: cover-1.sla
2009-09-14 22:51 N7DR File Added: cover-1-page1.jpg
2009-09-14 22:52 N7DR Note Added: 0022488
2009-09-15 05:01 christoph_s Note Added: 0022491
2009-09-15 20:17 cbradney Note Added: 0022492
2009-10-22 17:34 N7DR Note Added: 0022739
2009-10-22 17:52 jghali Note Added: 0022740
2009-10-28 19:56 N7DR Note Added: 0022761
2009-10-28 20:48 cbradney Note Added: 0022762
2009-10-28 21:28 N7DR Note Added: 0022763
2009-10-28 23:12 cbradney Note Added: 0022764
2014-09-18 21:41 Kunda Relationship added related to 0012679
2015-05-08 00:40 Kunda Relationship added child of 0013050