On 1. Aug 2019, at 19:47, Howard Chu hyc@symas.com wrote: =20 vporof@mozilla.com wrote:
Hey folks. =20 =3D46rom Myk=3DE2=3D80=3D99s investigations in the previous followup, =
it seems =3D
that the suggested changes to `mdb_cursor_init` to avoid using an =3D invalid DBI might not be solving the actual issue, given the =
behaviour =3D
of `mdb_page_search`.
=20 Agreed, that assert that I suggested isn't catching what we want.
FWIW, here's my findings when attempting to look into what was happening = with regards to that test case: = https://gist.github.com/victorporof/d1f98b8a52f79c7ff99f361d3a2adc3e
It's unclear how much overlap there is with the previous findings, and = whether or not calling `mdb_put` should assert with the DBI previously = opened via `mdb_dbi_open` with MDB_CREATE. Let me know if what I'm = observing here is expected.
=20
It=3DE2=3D80=3D99s also causing the seemingly correct test program to =
assert =3D
when it wasn=3DE2=3D80=3D99t before. It=3DE2=3D80=3D99s unclear =
whether this should =3D
be the case or not, perhaps Howard can confirm the expected =
behaviour.
=20 In any case, we=3DE2=3D80=3D99re wondering if there=3DE2=3D80=3D99s =
been any other =3D
progress, or if someone managed to reproduce this issue? Shipping new =
=3D
features built on top of LMDB in Firefox is currently blocked due to =
=3D
these failures, so any additional info would be helpful.
=20 Sorry, still not seeing this over here. What else do you know about =
the
systems where this is occurring? RAM size, storage on HDD / SSD / USB =
?
Here's everything we know about: = https://crash-stats.mozilla.org/report/index/5d77bd19-41ce-459f-9c1c-7f9fb= 0190324 See the "details" and "telemetry environment" sections for a = breakdown.
Victor
=20 --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
-
vporof＠mozilla.com