Comment 13 for bug 215904

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?