h...@symas.com wrote:
> Robins George wrote:
>> Hello Howard,
>
> Hello again. Revisiting this trace and walkthrough:
>
>> we are not able to reproduce the issue consistently so test code is not
>> available at this time, and I do believe this issue will be present in the
>> latest code as
Robins George wrote:
> Hello Howard,
Hello again. Revisiting this trace and walkthrough:
> we are not able to reproduce the issue consistently so test code is not
> available at this time, and I do believe this issue will be present in the
> latest code as well since Myk also reported the
That's good to know. Since we're completely in the dark on how to
produce a reliable test case that exercises this crash, the hope was
that fuzzing could inch us towards a solution.
There's also the problem that we're observing these crashes on Windows 7
and x86-64 (at least for now), as
h...@symas.com wrote:
> vpo...@mozilla.com wrote:
>> It might be possible that even though RKV was built in debug mode, the
>> backing sys crate isn't building LMDB itself this way. On a very first
>> glance it looks like this is the case, always going for opt level 2:
>>
vpo...@mozilla.com wrote:
> It might be possible that even though RKV was built in debug mode, the
> backing sys crate isn't building LMDB itself this way. On a very first
> glance it looks like this is the case, always going for opt level 2:
>
It might be possible that even though RKV was built in debug mode, the
backing sys crate isn't building LMDB itself this way. On a very first
glance it looks like this is the case, always going for opt level 2:
https://github.com/danburkert/lmdb-rs/blob/master/lmdb-sys/build.rs#L23
I'll have a
vpo...@mozilla.com wrote:
> Thanks for getting back!
>
> The files at https://github.com/mozkeeler/rkv-fuzz/tree/trunk/crashes
> are fuzzed variants of the input data seeded from the mdb input here:
> They're generated when running the `american fuzzy lop` fuzzer:
>
Thanks for getting back!
The files at https://github.com/mozkeeler/rkv-fuzz/tree/trunk/crashes
are fuzzed variants of the input data seeded from the mdb input here:
They're generated when running the `american fuzzy lop` fuzzer:
http://lcamtuf.coredump.cx/afl/.
Victor
vpo...@mozilla.com wrote:
> Quick update on this.
>
> Potentially useful to the efforts here, Dana Keeler has implemented a =
> fuzzing harness for RKV (our typed Rust interface to LMDB): =
> https://github.com/mozkeeler/rkv-fuzz
>
> We weren't able to trigger the `mdb_cursor_put` crashes
Quick update on this.
Potentially useful to the efforts here, Dana Keeler has implemented a =
fuzzing harness for RKV (our typed Rust interface to LMDB): =
https://github.com/mozkeeler/rkv-fuzz
We weren't able to trigger the `mdb_cursor_put` crashes reported at =
Apologies for the previous botched message, I was unfamiliar with the
formatting rules for this list.
To reiterate:
Since the link to the crash stats from my earlier reply now expired,
here's an up to date place to see all recent crash reports involving
`mdb_cursor_put`:
--Apple-Mail=_F8BCAB64-A19B-4B00-B41B-03BE06C12A1F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
> On 6. Aug 2019, at 13:43, Victor Porof wrote:
>=20
> Here's everything we know about: =
> On 1. Aug 2019, at 19:47, Howard Chu wrote:
>=20
> vpo...@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
vpo...@mozilla.com wrote:
> Hey folks.
>
> =46rom Myk=E2=80=99s investigations in the previous followup, it seems =
> that the suggested changes to `mdb_cursor_init` to avoid using an =
> invalid DBI might not be solving the actual issue, given the behaviour =
> of `mdb_page_search`.
Agreed,
Hey folks.
=46rom Myk=E2=80=99s investigations in the previous followup, it seems =
that the suggested changes to `mdb_cursor_init` to avoid using an =
invalid DBI might not be solving the actual issue, given the behaviour =
of `mdb_page_search`.
It=E2=80=99s also causing the seemingly correct
After stepping through the test program in a debugger, I see that
mdb_page_search returns MDB_NOTFOUND if mc->mc_db->md_root is P_INVALID
because the tree is empty. And mdb_cursor_put sets rc to MDB_NO_ROOT if
mc->mc_db->md_root is P_INVALID.
So that can't be related to the crash, at least
m...@mykzilla.org wrote on 2019-06-20 23:39:
> m...@mykzilla.org wrote on 2019-06-20 23:35:
>> I'm unsure if it's related, but with this change to mdb.c, the following
>> test program (which resembles Firefox's usage) asserts in
>> mdb_cursor_init because rc is MDB_NOTFOUND.
> Erm, here's the
m...@mykzilla.org wrote on 2019-06-20 23:35:
> I'm unsure if it's related, but with this change to mdb.c, the following
> test program (which resembles Firefox's usage) asserts in
> mdb_cursor_init because rc is MDB_NOTFOUND.
Erm, here's the program without the errant characters:
#include
h...@symas.com wrote on 2019-06-19 09:55:
> Maybe. For testing purposes you could try something like this
> diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c
> index 692feaa38b..e41f3bc36a 100644
> --- a/libraries/liblmdb/mdb.c
> +++ b/libraries/liblmdb/mdb.c
> @@ -7620,7 +7620,8 @@
m...@mykzilla.org wrote:
> h...@symas.com wrote on 2019-06-18 01:30:
>> There is no issue with mdb_cursor_put then. The question is why didn't
>> mdb_page_search find the DBI's root node?
> Would it be useful for mdb_cursor_init to return the result code of
> mdb_page_search, and for mdb_put to
h...@symas.com wrote on 2019-06-18 01:30:
> There is no issue with mdb_cursor_put then. The question is why didn't
> mdb_page_search find the DBI's root node?
Would it be useful for mdb_cursor_init to return the result code of
mdb_page_search, and for mdb_put to then return that code if it isn't
Robins George wrote:
> Hello Howard,
> we are not able to reproduce the issue consistently so test code is not
> available at this time, and I do believe this issue will be present in the
> latest code as well since Myk also reported the same.. Attaching analysis
> from our side, hope it
SGVsbG8gSG93YXJkLA0Kd2UgYXJlIG5vdCBhYmxlIHRvIHJlcHJvZHVjZSB0aGUgaXNzdWUgY29u
c2lzdGVudGx5IHNvIHRlc3QgY29kZSBpcyBub3QgYXZhaWxhYmxlIGF0IHRoaXMgdGltZSwgYW5k
IEkgZG8gYmVsaWV2ZSB0aGlzIGlzc3VlIHdpbGwgYmUgcHJlc2VudCBpbiB0aGUgbGF0ZXN0IGNv
h...@symas.com wrote on 2019-06-17 05:25:
> grob...@pulsesecure.net wrote:
>> I am seeing LMDB crash, please find the stack trace.
>>
>> #0 0x009e362e in mdb_cursor_put (mc=0xffd59bb8, key=0xffd59d14,
>> data=0xffd59d0c, flags=0) at mdb.c:6688
>> #1 0x009e48ec in mdb_put (txn=0xd74d3008, dbi=2,
grob...@pulsesecure.net wrote:
> Full_Name: Robins George
> Version: 0.9.18
> OS: Centos
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (121.244.154.134)
>
>
> I am seeing LMDB crash, please find the stack trace.
>
> #0 0x009e362e in mdb_cursor_put (mc=0xffd59bb8,
Full_Name: Robins George
Version: 0.9.18
OS: Centos
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (121.244.154.134)
I am seeing LMDB crash, please find the stack trace.
#0 0x009e362e in mdb_cursor_put (mc=0xffd59bb8, key=0xffd59d14,
data=0xffd59d0c, flags=0) at mdb.c:6688
#1
26 matches
Mail list logo
