1610797 - Crash in [@ nsLDAPSSLClose]

Status: RESOLVED FIXED

(Thunderbird :: General, defect)

Description

[Wayne Mery (:wsmwk)]

crash is new with 68.3.0. Variety of crash addresses

bp-41813288-f64c-4e5d-9b6b-ca7a50191205 68.3.0 0x0
bp-8b31771c-b470-4865-b0ce-073500200122 68.4.1 0xffffffffffffffff
bp-0f3ae5b5-522c-48d8-8d01-589c00200122. 68.4.1 0xff1471ff

Top 10 frames of crashing thread:

0 xul.dll nsLDAPSSLClose comm/ldap/xpcom/src/nsLDAPSecurityGlue.cpp:70
1 ldap60.dll nsldapi_close_connection comm/ldap/c-sdk/libraries/libldap/os-ip.c:737
2 ldap60.dll nsldapi_free_connection comm/ldap/c-sdk/libraries/libldap/request.c:761
3 ldap60.dll nsldapi_free_request comm/ldap/c-sdk/libraries/libldap/request.c:953
4 ldap60.dll nsldapi_free_request comm/ldap/c-sdk/libraries/libldap/request.c:949
5 ldap60.dll nsldapi_result_nolock comm/ldap/c-sdk/libraries/libldap/result.c:134
6 ldap60.dll ldap_result comm/ldap/c-sdk/libraries/libldap/result.c:104
7 xul.dll nsLDAPConnectionRunnable::Run comm/ldap/xpcom/src/nsLDAPConnection.cpp:626
8 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1175
9 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:486

Comment 1

[Wayne Mery (:wsmwk)]

And RtlEnterCriticalSection | je_free | nsLDAPSSLClose -- https://crash-stats.mozilla.com/signature/?product=Thunderbird&signature=RtlEnterCriticalSection%20%7C%20je_free%20%7C%20nsLDAPSSLClose&date=%3E%3D2019-10-22T12%3A39%3A00.000Z&date=%3C2020-01-22T12%3A39%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=startup_crash&_sort=-date&page=1#summary

Comment 2

[Wayne Mery (:wsmwk)]

and prldap_get_socket_info -- https://crash-stats.mozilla.com/signature/?product=Thunderbird&signature=prldap_get_socket_info&date=%3E%3D2019-10-22T12%3A41%3A00.000Z&date=%3C2020-01-22T12%3A41%3A00.000Z

Comment 3

[Wayne Mery (:wsmwk)]

So far, only version 68. ~top50 when including prldap_get_socket_info bp-a4ddc8df-4108-49c1-b8da-ff3240200214

Comment 4

[Magnus Melin [:mkmelin]]

Attachment: bug1610797_ldap_socketSesssion_crash.patch

For some reason there is no soinfo_appdata.

Comment 5

[Ben Campbell]

Comment on attachment 9155635 [details] [diff] [review]
bug1610797_ldap_socketSesssion_crash.patch

Review of attachment 9155635 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good. Perhaps it could be a StartTLS connection which was never upgraded? (eg shutting down before the StartTLS completed, or even where the server didn't support StartTLS after all...)

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/98363486b335
Fix crash in [@ nsLDAPSSLClose]. r=benc

Comment 7

[Magnus Melin [:mkmelin]]

Comment on attachment 9155635 [details] [diff] [review]
bug1610797_ldap_socketSesssion_crash.patch

Review of attachment 9155635 [details] [diff] [review]:
-----------------------------------------------------------------

Crash fix.

Comment 8

[Wayne Mery (:wsmwk)]

Comment on attachment 9155635 [details] [diff] [review]
bug1610797_ldap_socketSesssion_crash.patch

Approved for beta.

Comment 9

[Wayne Mery (:wsmwk)]

Ben, would it be expected for these crash signatures to plummet with the release of 68.7.0 from your fixing of Bug 1063723 ? - crash in nsDocumentViewer::OnDonePrinting @ address 0x5a5a5a5a/e5e5e5e9 use-afer-free (plummeted, but did not completely go away)

• https://crash-stats.mozilla.org/signature/?signature=nsLDAPSSLClose&date=%3E%3D2020-03-19T12%3A08%3A00.000Z&date=%3C2020-06-19T12%3A08%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=startup_crash&_sort=-date&page=1#graphs
• https://crash-stats.mozilla.org/signature/?signature=prldap_get_socket_info&date=%3E%3D2020-03-19T12%3A16%3A00.000Z&date=%3C2020-06-19T12%3A16%3A00.000Z#graphs

Comment 10

[Ben Campbell]

(In reply to Wayne Mery (:wsmwk) from comment #9)

Ben, would it be expected for these crash signatures to plummet with the release of 68.7.0 from your fixing of Bug 1063723 ? - crash in nsDocumentViewer::OnDonePrinting @ address 0x5a5a5a5a/e5e5e5e9 use-afer-free (plummeted, but did not completely go away)

No, I wouldn't expect any correlation between this and Bug 1063723 - even if the ultimate error (accessing bad memory) is the same, they get there via very different paths.

Comment 11

[Rob Lemley [:rjl]]

Thunderbird 78.0b3:
https://hg.mozilla.org/releases/comm-beta/rev/c8ac1cc10b1a