Hmmm, *lc is completely bogus. 7f3a11313ab0 is clearly in the text segment of the process, and the values starting from lconn_sasl_sockctx are ASCII:
00: 6d 70 2f 6f 70 65 6e 6c 64 61 70 32 2e 34 2e 37 mp/openldap2.4.7 01: 2f 6c 69 62 72 61 72 69 65 73 2f 6c 69 62 6c 62 /libraries/liblb 02: 6f 2e 63 3a 32 33 34 3a 20 62 65 72 73 68 32 3a o.c:234: bersh2: 03: 20 41 73 73 65 72 74 69 6f 6e 20 60 28 20 28 73 Assertion `( (s 04: 62 29 2d 3e 00 00 b)-> I.e., lc's contents are a copy of the actual text location where the assert message was stored. This would have made more sense if it was random data. Hard to see how a data or stack overwrite could cause pieces of the text segment to get copied into the heap, and ordinarily an assert/abort call doesn't trash the stack like this. Can you reproduce this bug when libldap, liblber, and nss_ldap are compiled without any optimization? -- (ITS#5518) Assertion error in io.c:234: ber_flush2 https://bugs.launchpad.net/bugs/215904 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap2.3 in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
