Signal #11 when get(ing) image

Previous topic - Next topic

jakobcornelis

I am getting signal #11 crashes when trying to get an image into an image frame.  I can not find any reference to this elsewhere.  I suspect I am doing something wrong.
The images are from  image files (jpg).  When I click on the file, I get the scribus crash warning.  Does this have anything to do with the image's size?  I scale them to approximately the frame size.  ???

[attachment deleted by admin]

utnik

hi jakob

what's your operating system and scribus version? – with scribus 1.4.3 on macOS 10.6.8 i imported your image in two of the frames of your .sla file without a problem...
how do you try to import? does the error occur with all the methods? ('file' → 'import' → 'get image', '⌘ i', right click, double click)

btw: the image is rather small. even for the width of a single text column, the resolution is as low as 105ppi – for the big frame it goes to no more than 52ppi. if it's for print (even on an office printer) i would try to have at least 140ppi...

utnik

jakobcornelis

Thanks, utnik.  I am running scribus 1.3.6. on a Linux distribution called Puppy.  The thing is, the first image - the big one - inserted OK.  The next one, with the two guys, at first caused Signal #11, for a while, but then I got it OK, too.  Problem is, I don't know how I did that.

And by the way, I agree the problem image is rather small.  I am considering leaving it out altogether. 

So far I am in principle delighted with Scribus - it's just that I am still in a steep learning curve.

I am importing by using the 'get image' after right-clicking in the image frame; then I select the image file in its folder where I keep the images I want to use for this newsletter.  I use my 'paint' program to size the image.  There is some reason why Scribus doesn't like the file I select, but I haven't figured out why not. 

Thanks for the response,

Jakob


GarryP

Jakob, it's probably a long shot but it's possible you could try using GIMP to "filter" or "clean" the image files.

Install GIMP, if you haven't got it already, then open each image and do a "File -> Export" to save it under a slightly different JPG name. Don't use "File -> Save As" as this will save as XCF which is GIMPs file format - not usable in Scribus.

I have no idea if this will work, or whether your image files need "filtering/cleaning", but it's worth a shot. Your paint program might be creating image files in some way that Scribus has problems with.

If your paint program is GIMP then what I've just said is pointless of course!

jakobcornelis

Thanks, Gary:  What beats me is that I got two other images to load to the page OK.  They were both processed in the same image editor (mtPaint).  I just don't know what I did differently before.  OK, I'll try to get GIMP - I think it is even listed as a package for my OS.

Jakob

jakobcornelis

OK, I installed GIMP, and now I can copy and paste directly from GIMP to Scribus.  Seems to work OK.  So, thanks for the suggestion, Garry, even if it was a long shot. (The only hitch is, now I gotta learn yet another program  ::)

utnik

hi jakob

Quote from: jakobcornelis on October 22, 2013, 08:45:48 PM...now I can copy and paste directly from GIMP to Scribus...

gimp is worth learning it – but 'copy & paste' is really not what i would recommend. this will blow up your .sla file and may lead to memory issues in files with lots of images!

utnik

jakobcornelis

OK, utnik, thanks for that.  I'll try and amend my ways, and use 'get image'.

Jake

GarryP

Jakob, I'm glad you've been able to get something to work and you can continue with your publication.

However, I'm still concerned that there still seems to be some problem somewhere, possibly either within Scribus or mtPaint, that is making some files incompatible between them - in some cases.

Quickly looking at the metadata in the file you uploaded it seems to be missing the "Resolution" and "Units" attributes so there's a chance that Scribus needs these - or needed on old versions - to use the file but one of the developers would have to answer that one. I may be barking up the wrong tree entirely.

As utnik has already demonstrated above, the problem seems to happen with one Scribus/OS combination (yours - 1.3.6/Puppy) but not with another combination (utnik's - 1.4.3/OSX), so whatever problem it is might have been fixed after 1.3.6, or it might be Linux-only, or it could be any number of other things.

Anyway, if someone reading this could pass it on to one of the developers it might make more sense to them and maybe they can give a real answer.

jakobcornelis

Garry, it would be extremely helpful if Scribus gave some reason for its inability to handle an image file, rather than simply crash, with the only explanation for that being something called Signal #11.  I still have no idea, after considerable searching, what that means.  I still have no idea either why some images wouldn't make it, while others did - in fact, one didn't at first, then did.  I just don't know what I did different when it did.  I haven't had any problems with GIMP so far (which I like better than mtPaint in any case), so I am not going to waste my time trying to figure all this out, which I do not have the competence to do anyway.   But hopefully someone besides myself can benefit from this thread.

Jakob

GarryP

I'm with you on Scribus' inability to report errors nicely when they happen.

In my experience - and from posts I've read in the forums - Scribus seems to do one of four things under error conditions:
1. Report a "Signal #6" error.
2. Report a "Signal #11" error.
3. Go into an "infinite" loop.
4. Just close down without any notice.

While the last two are very infrequent - and the third is probably because my machine doesn't have enough memory - I can't see how the first two are of any use for debugging purposes, never mind for normal users.

The developers do a really brilliant job but not having a decent error reporting system must give them loads of extra work to do hunting down the real causes of problems. And more work debugging means less time for other tasks.

P.S. On the technical side: I believe the "Signal #" numbers relate to very low-level run-time error conditions such as: invalid memory access; invalid instruction; divide by zero; etc. So, if this is the case, they're of no use to anyone either using the software or debugging it outside of the context in which they occurred. It might as well just say: "I've crashed for some reason or other.", and leave it at that.