[Top][All Lists]
[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, 11 Jul 2011 10:51:24 -0600 |
Thanks for finding that Fred, I bet that's it.
Germán, you could try a minimal test program like:
#import <Foundation/NSValue.h>
int main(int argc, const char **argv)
{
NSSize s = [((NSValue*)nil) sizeValue];
return 0;
}
and see if that segfaults on sparc.
Eric
On 2011-07-11, at 3:42 AM, Fred Kiefer wrote:
> 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.
>
> Fred
>
> 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)
>> return;
>>
>> after call [self nativeDrawInRect: dstRect fromRect: .... in line 1293.
>> But definitely this don't have sense. Fortunately debug=yes solve the
>> problem.
>>
>>
>> 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
>>>> 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
- Problem with Gorm, Germán Arias, 2011/07/01
- Re: Problem with Gorm, Eric Wasylishen, 2011/07/02
- Re: Problem with Gorm, Germán Arias, 2011/07/02
- Re: Problem with Gorm, Fred Kiefer, 2011/07/04
- Re: Problem with Gorm, Germán Arias, 2011/07/04
- Re: Problem with Gorm, Eric Wasylishen, 2011/07/04
- Re: Problem with Gorm, Germán Arias, 2011/07/04
- Re: Problem with Gorm, Germán Arias, 2011/07/08
- Re: Problem with Gorm, Fred Kiefer, 2011/07/11
- Re: Problem with Gorm, Germán Arias, 2011/07/11
- Re: Problem with Gorm,
Eric Wasylishen <=
- Re: Problem with Gorm, Germán Arias, 2011/07/11
- NSImage drawing (was Re: Problem with Gorm), Eric Wasylishen, 2011/07/04
- Re: NSImage drawing (was Re: Problem with Gorm), Fred Kiefer, 2011/07/05
- Re: NSImage drawing (was Re: Problem with Gorm), Quentin Mathé, 2011/07/06