discuss-gnustep
[Top][All Lists]
Advanced

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

Re: glyph generation errors in the layout manager


From: Eric Wasylishen
Subject: Re: glyph generation errors in the layout manager
Date: Wed, 20 Jul 2011 12:16:13 -0600

Hey Riccardo,

Looks to me like a bug in NSStringDrawing.m. It reuses a layout manager.

(aside: my first impression is it's certainly useful to keep a cache of strings 
-> metrics, since measuring strings is probably relatively expensive. I'm 
sceptical that reusing a layout manager saves a lot of time though.)

The comment at the top of the file says that none of the methods are reentrant, 
although every method acquires and releases a lock before doing anything with 
the shared layout manager, so I'm not sure about that.

It would be interesting to add some debugging code that records an array of 
threads the methods are called from, and see if they're ever called by a thread 
that's not the main thread.

I'll try to reproduce this with the latest Grr in GAP CVS.

Cheers
Eric

On 2011-07-20, at 7:04 AM, Riccardo Mottola wrote:

> Hi,
> 
> I tried to understand a little more what happens.
> 
> I set the breakpoint you recommended.
> I load Grr, I select an article which I know contains a link.
> 
> When moving the mouse pointer to the link, I can see this exception (which 
> was shown a couple of times before the spamming of the exceptions happened 
> yesterday)
> 
> 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:'
> 
> I got no exceptions, but trying to focus Grr again while writing the email, i 
> stopepd into the breakpoint twice. First most probably coming from the menu, 
> then I saw the typesetter exception:
> 
> 2011-07-20 14:57:17.355 Grr[2071] 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.
> 
> Breakpoint 2, -[GSLayoutManager(GlyphsHelpers) _generateGlyphsUpToCharacter:] 
> (
>    self=0xbadfc528, _cmd=0xbbbb1420, last=0) at GSLayoutManager.m:718
> 718           [NSException raise: NSGenericException
> 
> #0  -[GSLayoutManager(GlyphsHelpers) _generateGlyphsUpToCharacter:] (
>    self=0xbadfc528, _cmd=0xbbbb1420, last=0) at GSLayoutManager.m:718
> #1  0xbba7e6fb in -[GSLayoutManager(GlyphsHelpers) _generateGlyphsUpToGlyph:] 
> (
>    self=0xbadfc528, _cmd=0xbbbb1438, last=0) at GSLayoutManager.m:760
> #2  0xbba7e61b in -[GSLayoutManager(glyphs) glyphAtIndex:isValidIndex:] (
>    self=0xbadfc528, _cmd=0xbbbb2e78, glyphIndex=0, isValidIndex=0xbfbfd92b "")
>    at GSLayoutManager.m:865
> #3  0xbba84e40 in -[GSHorizontalTypesetter _cacheMoveTo:] (self=0xba340988,
>    _cmd=0xbbbb2f18, glyph=0) at GSHorizontalTypesetter.m:174
> #4  0xbba85589 in -[GSHorizontalTypesetter layoutLineNewParagraph:] (
>    self=0xba340988, _cmd=0xbbbb3048, newParagraph=1 '\001')
>    at GSHorizontalTypesetter.m:537
> #5  0xbba852cb in -[GSHorizontalTypesetter 
> layoutGlyphsInLayoutManager:inTextContainer:startingAtGlyphIndex:previousLineFragmentRect:nextGlyphIndex:numberOfLineFragments:]
>  (self=0xba340988, _cmd=0xbbbb14a0, layoutManager=0xbadfc528,
>    textContainer=0xbac47a98, glyphIndex=0, previousLineFragRect=
>        {origin = {x = 0, y = 0}, size = {width = 0, height = 0}},
>    nextGlyphIndex=0xbfbfddf8, howMany=0) at GSHorizontalTypesetter.m:1275
> #6  0xbba7fa67 in -[GSLayoutManager(LayoutHelpers) _doLayoutToContainer:] (
>    self=0xbadfc528, _cmd=0xbbbb1488, cindex=0) at GSLayoutManager.m:1946
> #7  0xbba81f8a in -[GSLayoutManager(layout) usedRectForTextContainer:] (
>    self=0xbadfc528, _cmd=0xbbb6d558, container=0xbac47a98)
>    at GSLayoutManager.m:2572
> #8  0xbb9dc28f in cache_lookup_string (string=0xba3f79e8,
>    attributes=0xba3f08b8, hasSize=0, size={width = 0, height = 0},
>    useScreenFonts=1) at NSStringDrawing.m:322
> #9  0xbb9dc4d3 in -[NSString(NSStringDrawing) sizeWithAttributes:] (
>    self=0xba3f79e8, _cmd=0xbbbc3250, attrs=0xba3f08b8)
>    at NSStringDrawing.m:747
> #10 0xbbaafa11 in -[GSTitleView titleSize] (self=0xbad40808, _cmd=0xbbb3e6b0)
>    at GSTitleView.m:204
> #11 0xbb977691 in -[NSMenuView sizeToFit] (self=0xbabcd908, _cmd=0xbbb3e6f0)
>    at NSMenuView.m:729
> #12 0xbb976769 in -[NSMenuView rectOfItemAtIndex:] (self=0xbabcd908,
>    _cmd=0xbbb3e6f8, index=3) at NSMenuView.m:952
> #13 0xbb97498d in -[NSMenuView setNeedsDisplayForItemAtIndex:] (
>    self=0xbabcd908, _cmd=0xbbb3e550, index=3) at NSMenuView.m:1019
> #14 0xbb974e91 in -[NSMenuView itemChanged:] (self=0xbabcd908,
>    _cmd=0xbbb3e4b0, notification=0xb9ee2188) at NSMenuView.m:463
> #15 0xbb574365 in -[NSNotificationCenter _postAndRelease:] (self=0xbad5e888,
>    _cmd=0xbb7981d0, notification=0xb9ee2188) at NSNotificationCenter.m:1223
> #16 0xbb5737e0 in -[NSNotificationCenter postNotification:] (self=0xbad5e888,
>    _cmd=0xbbb3b938, notification=0xb9ee2188) at NSNotificationCenter.m:1252
> #17 0xbb96ddde in -[NSMenu setMenuChangedMessagesEnabled:] (self=0xba381518,
>    _cmd=0xbbb3ba10, flag=1 '\001') at NSMenu.m:1473
> #18 0xbb972334 in -[NSMenu update] (self=0xba381518, _cmd=0xbbb3b958)
> 
> this tacktrace seems unrelated to the exception though and perhaps triggered 
> by the menu which lost focus when going into the debugger? However i stepped 
> through several hundred of "continue" and the exception trace remained the 
> same.
> 
> Riccardo
> 
> 
> 
> this appears to be triggered by the menu though.
> 
> 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




reply via email to

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