On the wikitext below, the named ref seems to have an empty dsr that crashed on 51be9c5e1f296e0ce55af639f2fc3cc7953a9409 but currently worked around on master. But, you can reproduce a different crasher by passing the '--dump dom:pre-dsr' or any other dom dumping command.
<poem>foo<ref name="x">''bar''</ref><ref name="x" /></poem>
You can find a few more crashers of the same type in https://logstash.wikimedia.org/app/dashboards#/view/parsoid-tests
It's easy enough to ignore nulls in massageLoadedDataParsoid(). I'm just wondering how the nulls got in there in the first place and whether they are my fault.
Maybe ignore the nulls for now and we'll redirect the task to investigating where the nulls came from separately.
Change 730651 had a related patch set uploaded (by Tim Starling; author: Tim Starling):
[mediawiki/services/parsoid@master] massageLoadedDataParsoid: Ignore null source ranges
This wikitext reproduces the problem:
<poem>foo<ref name="x">''bar''</ref></poem> <poem><ref name="x" /></poem>
The named ref in the second poem is necessary. The null on <i data-parsoid='{"dsr":null}'>bar</i> is present before the fixes, but doesn't crash it, but if I run php bin/parse.php --dump dom:pre-dsr < /tmp/wt, it crashes with other errors probably introduced by whatever is causing the null dsr.
Will retarget the bug report for debugging that.
Change 730651 merged by jenkins-bot:
[mediawiki/services/parsoid@master] massageLoadedDataParsoid: Ignore null source ranges
Change 731792 had a related patch set uploaded (by Subramanya Sastry; author: Subramanya Sastry):
[mediawiki/vendor@master] Bump wikimedia/parsoid to 0.15.0-a4
Change 731792 merged by jenkins-bot:
[mediawiki/vendor@master] Bump wikimedia/parsoid to 0.15.0-a4
Turns out the null dsr is legit ... the poem extension explicitly clears it out because it massages wikitext found within and so the computed DSR offsets don't correspond to top-level source and cannot be relied upon.