Servo shows grey screen instead of the monsterproof page

[suhr]

Now to reproduce: % ./mach run --release -e https://monsterproof.verigames.com/
OS: Linux x86_64

[mdinger]

I'm seeing this for every page now including the tests/html/about-mozilla.html. Not sure what the issue is. Tested with commit a914727

[mdinger]

Bisecting:

Works with 0d1dfb9 (after PR #9210)

[mdinger]

Works with e684a20 (after PR #9282)

[mdinger]

Works with 1ca2073 (after PR #9348)

[mdinger]

Fails with ff09924 (after PR #9366)

[mdinger]

Works with d9c6431 (after PR #9359)

[mdinger]

Works with 9d2eacf (after PR #9363)

[mdinger]

Fails with 74d75c4 (after PR #9364).

The problem started with 74d75c4 (PR #9364)

[jdm]

...huh. That's a very peculiar result. Could double check that a clobber build (ie. ./mach clean) on 74d75c4 and the revision right before it show the bad/good behaviour respectively?

[mdinger]

What I was doing was:

cd servo
git checkout -b new_name hash
sudo rm -r *
git reset --hard
./mach build --dev

The delete was with a gui because I wasn't sure if the command line would also remove the hidden files but that is basically what I did. Seems like that would be just as good as what you're suggesting.

[jdm]

I agree. Wow.

[jdm]

@glennw @mrobinson Any suggestions for investigating how a libc update caused servo to stop rendering anything?

[glennw]

Does using -o mode to output an image work?

[mdinger]

You mean like ./mach run -o www.google.com or like something else?

EDIT: I mean, I can check what the mach commands are next time I have linux up but until then, I'm just guessing.

[glennw]

Try ./mach run https://google.com -o output.png

[glennw]

(Or, perhaps try that with tests/html/about-mozilla.html first)

[mdinger]

-o output.png works properly with both tests/html/about-mozilla.html and google.com but normal running just generates a blank grey screen

[mbrubeck]

Works with 9d2eacf (after PR #9363)
Fails with 74d75c4 (after PR #9364).

The problem started with 74d75c4 (PR #9364)

That regression range also includes PR #9339. My testing shows that the first bad revision is actually f5c6c60 (#9339).

[mbrubeck]

Filed #9451 for this recent Linux-specific regression.

[suhr]

I guess this can be closed in favour of #9451?

[jdm]

Seems reasonable.

[mdinger]

Thanks @mbrubeck. I was actually trying to follow the bors PR merge order but apparently I failed. I did manually compare the branches and they appeared to only be a single commit apart. Comparing the servo tree is actually quite tricky because of the volume of commits and merges which occur. I'm glad you pointed out that trick!