On 1. Aug 2019, at 19:47, Howard Chu <hyc(a)symas.com> wrote:
=20
vporof(a)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/