Re: glyph generation errors in the layout manager

[Eric Wasylishen]

Hey Riccardo,
I think I fixed the problems..

Turns out the key was the first exception, "NSURL(instance) does not recognize 
length".

In this case the NSToolTipAttributeName attribute on the link was set to an 
NSURL. One problem was the -[NSTextView view:stringForToolTip:point:userData:] 
was assuming the NSToolTipAttributeName attribute value was an NSString. Now 
that method checks and calls -description on the object if the object isn't a 
string before returning it.

So before that fix, an NSURL was being returned, and the GSToolTips code was 
passing that to -[NSAttributedString initWithString:attributes:] as the string 
parameter, which accepted it! I also fixed NSAttributedString to throw an 
exception if the string parameter doesn't respond to -length (seems to match 
what Cocoa does.) 


For reference here's the backtrace for the first exception, 
2011-07-20 14:46:17.581 Grr[2071] *** NSTimer ignoring exception 
'NSInvalidArgumentException' (reason 'NSURL(instance) does not recognize 
length') raised during posting of timer with target 0xba0ff088 and selector 
'_timedOut:'

(gdb) bt
#0  -[NSException raise] (self=0x9ba930, _cmd=0x7ffff72bb280)
    at NSException.m:955
#1  0x00007ffff6e13e81 in +[NSException raise:format:] (self=0x7ffff72bb400, 
    _cmd=<value optimized out>, name=0x7ffff72bb470, format=0x7ffff733a640)
    at NSException.m:835
#2  0x00007ffff6f07b7f in GSFFIInvocationCallback (cif=0xbde350, 
    retp=0x7fffffffd4e0, args=0x7fffffffd360, user=0x9e62f0)
    at GSFFIInvocation.m:618
#3  0x00007ffff2b15c09 in ffi_closure_unix64_inner () from /usr/lib/libffi.so.5
#4  0x00007ffff2b15f94 in ffi_closure_unix64 () from /usr/lib/libffi.so.5
#5  0x00007ffff6d910ca in -[GSMutableString 
replaceCharactersInRange:withString:] (self=0xa61e50, _cmd=0x7ffff730a6c0, 
aRange=..., aString=0xcb0bd0)
    at GSString.m:4451
#6  0x00007ffff6eb02c8 in -[NSMutableString appendString:] (self=0xa61e50, 
    _cmd=<value optimized out>, aString=0xcb0bd0) at NSString.m:5350
#7  0x00007ffff7745be9 in -[GSTextStorage replaceCharactersInRange:withString:]
    (self=0xa61cf0, _cmd=0x7ffff7293f50, range=..., aString=0xcb0bd0)
    at GSTextStorage.m:800
#8  0x00007ffff6db19e5 in -[NSMutableAttributedString 
replaceCharactersInRange:withAttributedString:] (self=0xa61cf0, _cmd=<value 
optimized out>, aRange=..., 
    attributedString=0xc56a80) at NSAttributedString.m:1056
#9  0x00007ffff76a850b in cache_lookup_attributed_string (string=0xc56a80, 
    hasSize=0, size=..., useScreenFonts=1) at NSStringDrawing.m:357
---Type <return> to continue, or q <return> to quit---
#10 0x00007ffff76a9096 in -[NSAttributedString(NSStringDrawing) size] (
    self=0xc56a80, _cmd=0x7ffff7b9e130) at NSStringDrawing.m:560
#11 0x00007ffff779f529 in -[GSToolTips(Private) _timedOut:] (self=0xd5b640, 
    _cmd=0x7ffff7b9df20, aTimer=0xad4e60) at GSToolTips.m:606

So basically, -size was called on a NSAttributedString whose underlying string 
was an NSURL, and the exception that was thrown in a place where the edited 
count of the text storage used when measuring the string had been incremented, 
but was never decremented due to the exception.

--Eric

On 2011-07-20, at 8:23 AM, Riccardo Mottola wrote:

> Hi Fred,
> 
> If I remove the "tooltip" property from the link, I don't get the error 
> anymore. The tooltip didn't show up in any case (but they usually do work in 
> Vespucci).
> 
> Now even if I don't get exceptions, the links do not show properly formatted 
> (blue and underlined), although they show, work and have the proper mouse 
> cursor.
> 
> I hope this helps a little.
> 
> Riccardo
> 
> On 07/20/11 09:26, Fred Kiefer wrote:
>> On 19.07.2011 11:45, Riccardo Mottola wrote:
>>> I just fixed the Grr parser so that it displays some atttributes
>>> extracted from HTML inside the article. Most importantly, links!!! The
>>> bug was big I wonder how it ever had worked, I'd guess no but that's
>>> strange.
>>> 
>>> Anyway, now when displaying certain Articles the console gets spammed by:
>>> 
>>> 
>>> 2011-07-19 11:25:59.461 Grr[13239] GSHorizontalTypesetter - Glyph
>>> generation was triggered for a layout manager while the text storage it
>>> was attached to had unprocessed editing. This is not allowed. Glyph
>>> generation may be triggered only at points where calls to -beginEditing
>>> and -endEditing are balanced.
>>> 2011-07-19 11:25:59.461 Grr[13239] GSHorizontalTypesetter - Glyph
>>> generation was triggered for a layout manager while the text storage it
>>> was attached to had unprocessed editing. This is not allowed. Glyph
>>> generation may be triggered only at points where calls to -beginEditing
>>> and -endEditing are balanced.
>> 
>> Could you please add a break point in line 718 of the file GSLayoutManager.m 
>> and report back the back trace you get. That way we should be able to 
>> understand what is going on. Most likely we have a background thread that is 
>> changing the text while the gui thread is trying to lay it out. I am not 
>> sure what the best way to handle this could be. Maybe throw a specific 
>> exception here and handle it in the text view? I don't like the idea of 
>> adding more locks to the text processing.
>> 
>> _______________________________________________
>> Discuss-gnustep mailing list
>> Discuss-gnustep@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnustep
> 
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep