1167145 - nsBlockFrame: member call on null pointer of type

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Jonathan Kew [:jfkthame]]

+++ This bug was initially created as a clone of Bug #1167119 +++

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36

Steps to reproduce:

Add -fsanitize=null to compile options. This is second part of errors (#1165904):

- - - - -

Hidden among all the harfbuzz messages in bug 1167119 comment 0, there's one related to nsBlockFrame:

/home/marxin/Programming/gecko-dev/layout/generic/nsBlockFrame.cpp:6168:51: runtime error: member call on null pointer of type 'struct nsBlockFrame'

Comment 1

[Jonathan Kew [:jfkthame]]

Martin, could you please confirm exactly what revision you're building. Line nsBlockFrame.cpp:6168 in mozilla-central right now is a blank line, but most likely code has just moved around slightly.

Comment 2

[Martin Liška]

Hi.

I've been using following commit: https://github.com/mozilla/gecko-dev/commit/46f922660fcbe120c160f50b769c7eef26258820.

Motivation is that I am not sure if current Mozilla trunk is capable of success built by LTO.
Anyway, as all other errors are going to be resolved, I'm going to test Mozilla inbound (trunk).

Thanks,
Martin

Comment 3

[Jonathan Kew [:jfkthame]]

OK, so I guess that's referring to the ->FindTrailingClear() call, as seen here?

  http://hg.mozilla.org/mozilla-central/annotate/11e7ca322c9d/layout/generic/nsBlockFrame.cpp#l6168

That's now at line 6151, but I suspect the problem still exists. (Confirmation from your trunk test would be great, thanks!)

Comment 4

[Martin Liška]

Right, just finished testing, I can confirm that:
/home/marxin/Programming/gecko-dev/layout/generic/nsBlockFrame.cpp:6151:51: runtime error: member call on null pointer of type 'struct nsBlockFrame'

Thanks,
Martin

Comment 5

[Jonathan Kew [:jfkthame]]

Attachment: Check result of PrevInFlow() before trying to call a method on it

Presumably this will prevent the error reported here. Is this sufficient, or does this indicate a deeper underlying problem of some kind?

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 8608838 [details] [diff] [review]
Check result of PrevInFlow() before trying to call a method on it

There might be something a little weird going on here, but I don't think it's worth digging into.  (... I say after 10 minutes of doing exactly that.)

Comment 7

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/ea0858f7f19f

Comment 8

[Ekanan Ketunuti]

https://hg.mozilla.org/mozilla-central/rev/ea0858f7f19f