|
|
Please provide sample docs that crash Scribus. Sometimes it will not be possible to find out why (via code) |
|
2009-09-14 22:49
|
|
|
2009-09-14 22:51
|
cover-1-page1.jpg (709,370 bytes) |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
>> 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. |
|
|
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. |
|
|
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. |
|
|
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". |
|
|
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). |
- Anonymous
