WebPositive (master) - random crashes

[vidrep]

hrev56671 x86_64

HaikuWebKit 1.9.1 WebKit 615.1.10

Random crashes of app_server when using WebPositive

Debug report and photo attached

[waddlesplash]

NULL dereference in the font code. Unsurprising as this was just refactored.

[madmax]

Any hint on how to improve the chance of hitting this?

I've stumbled upon two places that may incorrectly delete a FontFamily so that a later search may lead to this, but they require an allocation error or a very long style name, and even that wouldn't be enough by itself. If there's a site you've always visited when you had this crash (not necessarily open the very same moment the crash happens) and it uses a font with a wild name, that may be it. But until so proven it may be a different cause.

[pulkomandy]

Can you clarify where you see a NULL derefernce? The crashing instruction is mov (%rsi,%rdx),%ecx which translates to "read memory at RSI+RDX and write to register ECX".

RSI is not 0 so that is not a NULL pointer at all. RDX is 0 and is the osset into the string (so we're just accessing the first 4 bytes of it).

So it is not a NULL, but a completely uninitialized or otherwise corrupt pointer?

[madmax]

Fixed in hrev56765.

Observed with icons font in DuckDuckGo. It sometimes loads with no style name. A later visit sometimes loads fonts again. In that case, when we get to _AddUserFont:

1. We check if we already have that family. We do, so we'll use that instead of creating a new one.
2. We ask the family if it already has this face. HasStyle calls _FindStyle, that doesn't like the empty style name and says there's no such face.
3. We create the new style.
4. We AddStyle to the family. This one checks again if the family already has that style, but does so directly, not through _FindStyle, and not checking if the style name is empty. So it finds the former style, doesn't add the new one and says so in the return value.
5. As we didn't add the style, we delete it and also the not new family. OUCH.

The next search by family name that touches that item crashes apps_server. If that doesn't happen, it crashes anyway on WebPositive exit when cleaning up the font manager.

There's still the question of whether the font is really sent with an empty style name or there's a bug somewhere else, and what to do with empty style names (and even family names) if they are legal. At least for svg fonts those are optional attributes without default values.