Crash while closing LDAP connections
Categories
(Thunderbird :: Address Book, defect)
Tracking
(Not tracked)
People
(Reporter: cmgaudry33, Unassigned)
Details
Attachments
(1 file, 1 obsolete file)
(deleted),
application/octet-stream
|
Details |
Thunderbird 78.5.1 crashes every time an LDAP connection is closed.
In Thunderbird 78.5.0 everything is ok.
Steps to reproduce:
- Open a command line window
- Set environment variable NSPR_LOG_MODULES = LDAP: 5
- Start Thunderbird from the command line (to get standard output).
- Configure the new LDAP address book using the ldaps protocol and simple binding.
- Open the Address books window.
- Select the newly created address book.
- search for something in this address book.
- Close the Address books window.
- Close the main window.
Output :
[(null) 8388: Main Thread]: D/LDAP nsLDAPOperation::SimpleBind(): called; bindName = '';
[(null) 8388: Socket Thread]: D/LDAP Operation id=1 added (1 now pending)
[(null) 8388: Socket Thread]: D/LDAP pending operation removed; total pending operations now = 0
[(null) 8388: Main Thread]: D/LDAP nsLDAPOperation::SearchExt(): called with aBaseDn = 'xxxxxxxxx'; aFilter = 'xxxxxxxxx'; aAttributes = xxxxxxxxx; aSizeLimit = 100
[(null) 8388: Socket Thread]: D/LDAP Operation id=2 added (1 now pending)
[(null) 8388: Socket Thread]: D/LDAP pending operation removed; total pending operations now = 0
[(null) 8388: Main Thread]: D/LDAP nsLDAPOperation::SimpleBind(): called; bindName = '';
[(null) 8388: Socket Thread]: D/LDAP Operation id=1 added (1 now pending)
[(null) 8388: Socket Thread]: D/LDAP pending operation removed; total pending operations now = 0
[(null) 8388: Main Thread]: D/LDAP nsLDAPOperation::SearchExt(): called with aBaseDn = 'xxxxxxxxx'; aFilter = 'xxxxxxxxx'; aAttributes = xxxxxxxxx; aSizeLimit = 100
[(null) 8388: Socket Thread]: D/LDAP Operation id=2 added (1 now pending)
[(null) 8388: Socket Thread]: D/LDAP pending operation removed; total pending operations now = 0
[(null) 8388: Main Thread]: D/LDAP unbinding
The application exits with code 1.
The crashreporter is launched.
You can see that the "D/LDAP unbound" is missing from the standard output.
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Comment 1•4 years ago
|
||
This anomaly is really blocking. It is impossible for me to deploy such a version in production. Indeed, given the use of a custom component to interact with an LDAP server, the application crashes as soon as the interface starts up.
Comment 2•4 years ago
|
||
What's the crash id? See the crash ids in Help | Troubleshooting information (about:crashes)
Maybe bug 1673205?
Reporter | ||
Comment 3•4 years ago
|
||
I am working offline. So the crash report does not go back to Mozilla's servers. However, you will find an example of a crash report in attachment.
Comment 4•4 years ago
|
||
Sorry that's not a useful trace. Would need the stack, such you get it either through a mozilla crash report, or backtrace from crashing in a debugger.
Comment 5•4 years ago
|
||
Reporter | ||
Comment 6•4 years ago
|
||
Is it more useful ?
Comment 7•4 years ago
|
||
Comment on attachment 9191586 [details]
bug_1680492_1778dcf5-8652-4848-baff-92c6ceac94e9
Possibly but in a very very hard to figure out format.
If you let it submit the report, you get into a specific stack trace like https://crash-stats.mozilla.org/report/index/4c06420a-f3e2-4a58-a013-30ee20201207
Something like that.
Note: for non-patches, please just use needinfo.
Reporter | ||
Comment 8•4 years ago
|
||
I installed Thunderbird 78.5.1 on a public machine and added the LDAP address book (configured on the ldap.forumsys.com server), performed a search, closed the application.
I sent the following report:
https://crash-stats.mozilla.org/report/index/40b882fc-b057-4cf9-ab8a-0d3880201207
Updated•4 years ago
|
Description
•