[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem with Gorm

From: Fred Kiefer
Subject: Re: Problem with Gorm
Date: Mon, 11 Jul 2011 11:42:56 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv: Gecko/20110616 SUSE/3.1.11 Thunderbird/3.1.11

Here we got the size from rep before the test for nil. On some machines (sparc) such a call may lead to a segmentation fault. Not sure, whether this was your problem, but you should try again with current SVN to see if something changed.


On 09.07.2011 02:38, Germán Arias wrote:
Well, Gorm crash at line 959 in NSImage.m (when rep is equal to nil)

   if (rep == nil)

after call [self nativeDrawInRect: dstRect fromRect: .... in line 1293.
But definitely this don't have sense. Fortunately debug=yes solve the

On lun, 2011-07-04 at 12:23 -0600, Eric Wasylishen wrote:
That's really strange. I don't see any #ifdef's in NSImage.m.

Maybe you can try to compile without "debug=yes" (so you get the crash), but somehow add 
"-g" to the compile flags so debug info is generated. Do you get any info if you select stack frame 
0 and type "l" (for listing source code)?

On 2011-07-04, at 12:15 PM, Germán Arias wrote:

If the problem disappears with "debug=yes". Could be the cause a code
line inside a #ifdef DEBUG? A code line that should be outside of that

On lun, 2011-07-04 at 10:41 +0200, Fred Kiefer wrote:
Which backend are you using? That will result in different methods being
called next and most likely the problem is one level deeper.

I had a quick look into these new methods and didn't like too much what
I saw there. We have a lot of code duplication between these two
methods, but we also have differences there which I don't understand.
Why do we use scaling for the native drawing but not for the gui drawing?
Anyway, the code in native drawing should not check for
isDrawingToScreen. When drawing to a PDF or PostScript surface we should
be able to composite or dissolve, we just need to package that up
correctly as backend operations. And of course need to have the PS and
PDF context report back that they are able to support this.

I also noticed that the new code wont fill the cached image rep with the
image background colour. Why isn't this done and does this match the
Cocoa behaviour?
Why does the old code (guiDrawInRect:...) use PSgsave and PSgrestore
around the cache drawing? We wont do any other operations on the cache
and don't need to restore the old state.

I think that we should start a discussion about this whole drawing code.
Hopefully we end up with a deeper understanding of what should happen
here and will then be able to package it up with a nice and clean call
to the backend and three or four (almost?) correct implementations for
this in GSContext, GSStreamContext and GSCairoContext. But then I may be
completely wrong here, as I really don't understand much of this new code.

On 03.07.2011 01:49, Germán Arias wrote:
Well, after compiling gui with "debug=yes" all works fine. But then,
recompiling gui just with "make" the problem is there again.

On sáb, 2011-07-02 at 11:36 -0600, Eric Wasylishen wrote:
Hey German,
I wasn't able to reproduce that in Gorm or Gemas, but it looks like it's coming 
from code I've worked on lately...
Frame 1 of the backtrace is just the line which redirects -drawInRect: to 
-guiDrawInRect:, but frame 0 has no debug info. Would you be able to recompile 
-gui (and maybe -back as well) with debugging on (just make clean and make 
debug=yes), and see if it you can get a better backtrace? Thanks.

On 2011-07-01, at 4:20 PM, Germán Arias wrote:

When I select "Containers Palette" the app crash. The backtrace is:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb669fb30 (LWP 6463)]
0x0847ac03 in ?? ()
(gdb) backtrace
#0  0x0847ac03 in ?? ()
#1  0xb7344734 in -[NSImage drawInRect:fromRect:operation:fraction:] (
    self=0x86385f8, _cmd=0xb759a358, dstRect=
        {origin = {x = 0, y = 0}, size = {width = 0, height = 0}},
        {origin = {x = 0, y = 0}, size = {width = 0, height = 0}},
    op=NSCompositeSourceOver, delta=1) at NSImage.m:1297
#2  0xb73405dd in -[NSImage drawAtPoint:fromRect:operation:fraction:] (
    self=0x86385f8, _cmd=0xb759a320, point={x = 0, y = 0}, srcRect=
        {origin = {x = 0, y = 0}, size = {width = 0, height = 0}},
    op=NSCompositeSourceOver, delta=1) at NSImage.m:925
#3  0xb7344650 in -[NSImage
compositeToPoint:fromRect:operation:fraction:] (
    self=0x86385f8, _cmd=0xb759a2d0, aPoint={x = 0, y = 9}, srcRect=
        {origin = {x = 0, y = 0}, size = {width = 0, height = 0}},
    op=NSCompositeSourceOver, delta=1) at NSImage.m:864
#4  0xb73402a1 in -[NSImage compositeToPoint:operation:]
    _cmd=0xb756f658, aPoint={x = 0, y = 9}, op=NSCompositeSourceOver)
    at NSImage.m:811
#5  0xb72df7dc in -[NSCell drawInteriorWithFrame:inView:]
    _cmd=0xb756f668, cellFrame=
        {origin = {x = 0, y = 0}, size = {width = 9, height = 9}},
    controlView=0x86393f0) at NSCell.m:2031
#6  0x086385f8 in ?? ()
#7  0xb756f658 in _OBJC_SELECTOR_TABLE ()
   from /usr/GNUstep/Local/Library/Libraries/
---Type<return>   to continue, or q<return>   to quit---
#8  0x00000000 in ?? ()

FisicaLab also crash, when you open the help panel, with a similar

reply via email to

[Prev in Thread] Current Thread [Next in Thread]