Re: Problem with Gorm

[Germán Arias]

Runs fine. But my processor is a Pentium.

On lun, 2011-07-11 at 10:51 -0600, Eric Wasylishen wrote:
> 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
> 
> 
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev