logging error in nsSmtpProtocol::AuthLoginStep1

RESOLVED FIXED in Thunderbird 54.0

Status

MailNews Core
Networking: SMTP
RESOLVED FIXED
a year ago
a year ago

People

(Reporter: Daniel Kahn Gillmor, Assigned: aceman)

Tracking

Trunk
Thunderbird 54.0

Thunderbird Tracking Flags

(thunderbird52+ fixed, thunderbird53 fixed, thunderbird54 fixed)

Details

Attachments

(1 attachment)

1.15 KB, patch
Jorg K (GMT+2) (bustage-fix only, NI for urgent reviews)
: review+
aceman
: feedback?
Daniel Kahn Gillmor
Jorg K (GMT+2) (bustage-fix only, NI for urgent reviews)
: approval-comm-aurora+
Jorg K (GMT+2) (bustage-fix only, NI for urgent reviews)
: approval-comm-beta+
Details | Diff | Splinter Review
(Reporter)

Description

a year ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20170205065236

Steps to reproduce:

launch thunderbird with:

NSPR_LOG_MODULES=smtp:5 NSPR_LOG_FILE=/tmp/thunderbird.log thunderbird

compose and send a message.


Actual results:

the log /tmp/thunderbird.log will contain something like:

 -321738944[7fb1eb8a2380]: SMTP AuthLoginStep1() for testuser@example.com@<90><F6>^K<EA><B1>^?

that trailing garbage is bad!  it should represent a string-like version 




Expected results:


https://dxr.mozilla.org/comm-central/source/mailnews/compose/src/nsSmtpProtocol.cpp#1460

shows that what should be a string pointer is being retrieved from an nsCOMPtr<nsISmtpServer>.get() function, which is just a nsISmtpServer* -- i think it should be calling GetHostname or GetDescription or something comparable instead of handing a raw pointer to the logging function.
Thank you for the report, happens both with 45.7.1 and latest Trunk (54.0a1).
Status: UNCONFIRMED → NEW
Component: Untriaged → Networking: SMTP
Ever confirmed: true
Product: Thunderbird → MailNews Core
Version: 45 Branch → Trunk
(Assignee)

Comment 2

a year ago
Yes, that print is bad.
Assignee: nobody → acelists
Status: NEW → ASSIGNED
OS: Unspecified → All
Hardware: Unspecified → All
Thanks. Synchronicity. We discovered this ourselves today, see bug 1340755.

Current try run here:
https://hg.mozilla.org/try-comm-central/rev/9ea6e1d79df318564e0b2b7272ccc80a627f68f8#l3.42

We'll get this fixed in TB 52 beta 4 and the next TB 52 ESR due in March 2017.
Aceman, we just need a patch for C-A and C-B, C-C will be fixed in bug 1340755.
status-thunderbird52: --- → affected
status-thunderbird53: --- → affected
status-thunderbird54: --- → affected
tracking-thunderbird52: --- → +
(Assignee)

Comment 5

a year ago
Created attachment 8838880 [details] [diff] [review]
patch

Can you try this?
Attachment #8838880 - Flags: review?(jorgk)
Attachment #8838880 - Flags: feedback?(dkg)
Comment on attachment 8838880 [details] [diff] [review]
patch

Yep, but only for C-A and C-B. Or do you want to separate this out from the other patch? You decide, I'll approve anything ;-)
Attachment #8838880 - Flags: review?(jorgk) → review+
(Assignee)

Comment 7

a year ago
Yes, let's split this out of bug 1340755 as this is a functional change.
Fine, just land them together later then.
Comment on attachment 8838880 [details] [diff] [review]
patch

[Triage Comment]
Attachment #8838880 - Flags: approval-comm-beta+
Attachment #8838880 - Flags: approval-comm-aurora+
(Assignee)

Comment 10

a year ago
https://hg.mozilla.org/comm-central/rev/a0b08cd9413318c9df52e05f747ea42c64dc04fb
Status: ASSIGNED → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 54.0
Aurora (TB 53):
https://hg.mozilla.org/releases/comm-aurora/rev/ae9e786af6a170d6e18dca73a8d4c3a206b3e8e0
status-thunderbird53: affected → fixed
status-thunderbird54: affected → fixed
You need to log in before you can comment on or make changes to this bug.