gnustep-dev
[Top][All Lists]
Advanced

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

Re: Problem with Gorm


From: Eric Wasylishen
Subject: Re: Problem with Gorm
Date: Mon, 4 Jul 2011 12:23:53 -0600

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
> ifdef?
> 
> 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.
>>>> Eric
>>>> 
>>>> 
>>>> 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}},
>>>>> srcRect=
>>>>>        {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:]
>>>>> (self=0x86385f8,
>>>>>    _cmd=0xb756f658, aPoint={x = 0, y = 9}, op=NSCompositeSourceOver)
>>>>>    at NSImage.m:811
>>>>> #5  0xb72df7dc in -[NSCell drawInteriorWithFrame:inView:]
>>>>> (self=0x8600bf0,
>>>>>    _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/libgnustep-gui.so.0.21
>>>>> ---Type<return>  to continue, or q<return>  to quit---
>>>>> #8  0x00000000 in ?? ()
>>>>> (gdb)
>>>>> 
>>>>> FisicaLab also crash, when you open the help panel, with a similar
>>>>> backtrace.
>> 
>> 
>> _______________________________________________
>> Gnustep-dev mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
> 
> 
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev




reply via email to

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