Closed
Bug 932904
Opened 11 years ago
Closed 10 years ago
Use of uninitialized value on the heap: created by nsNntpIncomingServerConstructor()
Categories
(MailNews Core :: Networking: NNTP, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
Thunderbird 29.0
People
(Reporter: ishikawa, Assigned: ishikawa)
Details
Attachments
(1 file, 3 obsolete files)
3.15 KB,
patch
|
ishikawa
:
review+
|
Details | Diff | Splinter Review |
Use of uninitialized value on the heap: created by nsNntpIncomingServerConstructor() Detected by memcheck/valgrind. I see the following uninitialized value access errors during the |make mozmill| test suite run of comm-central thunderbird (source refreshed about 48 hours ago, and this is a DEBUG BUILD) under valgrind/memcheck. (I use a wrapper program to run thunderbird under valgrind). This did not happen when similar memcheck run on TB during |make mozmill| test was performed about a couple of weeks ago. So I think the regression is fairly recent (in October?). Or maybe we have a new test? Noticed on 64-bit Debian GNU/Linux. The following is the error mesasge: There are three error messages that appeared consecutively in the log. I think they all point to the same issue. So I list the first error only. ==13469== Conditional jump or move depends on uninitialised value(s) ==13469== at 0x406BF06: dosprintf (prprf.c:867) ==13469== by 0x406C643: PR_vsxprintf (prprf.c:1073) ==13469== by 0x925CF50: nsACString_internal::AppendPrintf(char const*, ...) (nsTSubstring.cpp:780) ==13469== by 0x89201DB: nsNntpIncomingServer::WriteHostInfoFile() [clone .part.33] (nsTSubstring.h:417) ==13469== by 0x8922062: nsNntpIncomingServer::StopPopulating(nsIMsgWindow*) (nsNntpIncomingServer.cpp:795) ==13469== by 0x891D6C1: nsNntpIncomingServer::OnStopRunningUrl(nsIURI*, tag_nsresult) (nsNntpIncomingServer.cpp:722) ==13469== by 0x854F6AB: nsMsgMailNewsUrl::SetUrlState(bool, tag_nsresult) (nsMsgMailNewsUrl.cpp:97) ==13469== by 0x8940464: nsNNTPProtocol::CleanupAfterRunningUrl() (nsNNTPProtocol.cpp:4735) ==13469== by 0x89465EF: nsNNTPProtocol::ProcessProtocolState(nsIURI*, nsIInputStream*, unsigned long, unsigned int) (nsNNTPProtocol.cpp:4652) ==13469== by 0x85554C3: nsMsgProtocol::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned long, unsigned int) (nsMsgProtocol.cpp:353) ==13469== by 0x6DF00F0: nsInputStreamPump::OnStateTransfer() (nsInputStreamPump.cpp:592) ==13469== by 0x6DF06D7: nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) (nsInputStreamPump.cpp:433) ==13469== by 0x9206200: nsInputStreamReadyEvent::Run() (nsStreamUtils.cpp:85) ==13469== by 0x9223FF1: nsThread::ProcessNextEvent(bool, bool*) (nsThread.cpp:622) ==13469== by 0x924CA6D: NS_InvokeByIndex (xptcinvoke_x86_64_unix.cpp:164) ==13469== by 0x8075AF4: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (XPCWrappedNative.cpp:2797) ==13469== by 0x8082219: XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) (XPCWrappedNativeJSOps.cpp:1311) ==13469== by 0x9BE32AA: js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) (jscntxtinlines.h:220) ==13469== by 0x9BE052D: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (Interpreter.cpp:462) ==13469== by 0x9BD95BC: Interpret(JSContext*, js::RunState&) (Interpreter.cpp:2499) ==13469== by 0x9BE0308: js::RunScript(JSContext*, js::RunState&) (Interpreter.cpp:419) ==13469== by 0x9BE077A: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (Interpreter.cpp:481) ==13469== by 0x9BE0FA9: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) (Interpreter.cpp:512) ==13469== by 0x9B24B6A: js::DirectProxyHandler::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jsproxy.cpp:454) ==13469== by 0x9B83919: js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jswrapper.cpp:454) ==13469== by 0x9B257D6: js::Proxy::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jsproxy.cpp:2643) ==13469== by 0x9B258F7: proxy_Call(JSContext*, unsigned int, JS::Value*) (jsproxy.cpp:3037) ==13469== by 0x9BE32AA: js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) (jscntxtinlines.h:220) ==13469== by 0x9BE052D: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (Interpreter.cpp:462) ==13469== by 0x9BD95BC: Interpret(JSContext*, js::RunState&) (Interpreter.cpp:2499) ==13469== by 0x9BE0308: js::RunScript(JSContext*, js::RunState&) (Interpreter.cpp:419) ==13469== by 0x9BE077A: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (Interpreter.cpp:481) ==13469== by 0x9BE0FA9: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) (Interpreter.cpp:512) ==13469== by 0x9B24B6A: js::DirectProxyHandler::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jsproxy.cpp:454) ==13469== by 0x9B83919: js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jswrapper.cpp:454) ==13469== by 0x9B257D6: js::Proxy::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jsproxy.cpp:2643) ==13469== by 0x9B258F7: proxy_Call(JSContext*, unsigned int, JS::Value*) (jsproxy.cpp:3037) ==13469== by 0x9BE32AA: js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) (jscntxtinlines.h:220) ==13469== by 0x9BE052D: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (Interpreter.cpp:462) ==13469== by 0x9BD95BC: Interpret(JSContext*, js::RunState&) (Interpreter.cpp:2499) ==13469== by 0x9BE0308: js::RunScript(JSContext*, js::RunState&) (Interpreter.cpp:419) ==13469== by 0x9BE077A: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (Interpreter.cpp:481) ==13469== by 0x9BE0FA9: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) (Interpreter.cpp:512) ==13469== by 0x9B24B6A: js::DirectProxyHandler::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jsproxy.cpp:454) ==13469== by 0x9B83919: js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jswrapper.cpp:454) ==13469== by 0x9B257D6: js::Proxy::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jsproxy.cpp:2643) ==13469== by 0x9B258F7: proxy_Call(JSContext*, unsigned int, JS::Value*) (jsproxy.cpp:3037) ==13469== by 0x9BE32AA: js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) (jscntxtinlines.h:220) ==13469== by 0x9BE052D: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (Interpreter.cpp:462) ==13469== by 0x9BD95BC: Interpret(JSContext*, js::RunState&) (Interpreter.cpp:2499) ==13469== Uninitialised value was created by a heap allocation ==13469== at 0x402A914: malloc (vg_replace_malloc.c:291) ==13469== by 0x4046093: moz_xmalloc (mozalloc.cpp:54) ==13469== by 0x8502BD3: nsNntpIncomingServerConstructor(nsISupports*, nsID const&, void**) (mozalloc.h:201) ==13469== by 0x921AAC6: nsComponentManagerImpl::CreateInstanceByContractID(char const*, nsISupports*, nsID const&, void**) (nsComponentManager.cpp:1096) ==13469== by 0x91ABE9F: nsCreateInstanceByContractID::operator()(nsID const&, void**) const (nsComponentManagerUtils.cpp:178) ==13469== by 0x852B62C: nsCOMPtr<nsIMsgIncomingServer>::assign_from_helper(nsCOMPtr_helper const&, nsID const&) (nsCOMPtr.h:1259) ==13469== by 0x859031C: nsMsgAccountManager::createKeyedServer(nsACString_internal const&, nsACString_internal const&, nsACString_internal const&, nsACString_internal const&, nsIMsgIncomingServer**) (nsCOMPtr.h:637) ==13469== by 0x85909CC: nsMsgAccountManager::CreateIncomingServer(nsACString_internal const&, nsACString_internal const&, nsACString_internal const&, nsIMsgIncomingServer**) (nsMsgAccountManager.cpp:458) ==13469== by 0x924CA6D: NS_InvokeByIndex (xptcinvoke_x86_64_unix.cpp:164) ==13469== by 0x8075AF4: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (XPCWrappedNative.cpp:2797) ==13469== by 0x8082219: XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) (XPCWrappedNativeJSOps.cpp:1311) ==13469== by 0x9BE32AA: js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) (jscntxtinlines.h:220) ==13469== by 0x9BE052D: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (Interpreter.cpp:462) ==13469== by 0x9BD95BC: Interpret(JSContext*, js::RunState&) (Interpreter.cpp:2499) ==13469== by 0x9BE0308: js::RunScript(JSContext*, js::RunState&) (Interpreter.cpp:419) ==13469== by 0x9BE077A: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (Interpreter.cpp:481) ==13469== by 0x9BE0FA9: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) (Interpreter.cpp:512) ==13469== by 0x9B24B6A: js::DirectProxyHandler::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jsproxy.cpp:454) ==13469== by 0x9B83919: js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jswrapper.cpp:454) ==13469== by 0x9B257D6: js::Proxy::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jsproxy.cpp:2643) ==13469== by 0x9B258F7: proxy_Call(JSContext*, unsigned int, JS::Value*) (jsproxy.cpp:3037) ==13469== by 0x9BE32AA: js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) (jscntxtinlines.h:220) ==13469== by 0x9BE052D: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (Interpreter.cpp:462) ==13469== by 0x9BD95BC: Interpret(JSContext*, js::RunState&) (Interpreter.cpp:2499) ==13469== by 0x9BE0308: js::RunScript(JSContext*, js::RunState&) (Interpreter.cpp:419) ==13469== by 0x9BE077A: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (Interpreter.cpp:481) ==13469== by 0x9BE0FA9: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) (Interpreter.cpp:512) ==13469== by 0x9B24B6A: js::DirectProxyHandler::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jsproxy.cpp:454) ==13469== by 0x9B83919: js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jswrapper.cpp:454) ==13469== by 0x9B257D6: js::Proxy::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jsproxy.cpp:2643) ==13469== by 0x9B258F7: proxy_Call(JSContext*, unsigned int, JS::Value*) (jsproxy.cpp:3037) ==13469== by 0x9BE32AA: js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) (jscntxtinlines.h:220) ==13469== by 0x9BE052D: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (Interpreter.cpp:462) ==13469== by 0x9BD95BC: Interpret(JSContext*, js::RunState&) (Interpreter.cpp:2499) ==13469== by 0x9BE0308: js::RunScript(JSContext*, js::RunState&) (Interpreter.cpp:419) ==13469== by 0x9BE077A: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (Interpreter.cpp:481) ==13469== by 0x9A91BD6: js_fun_apply(JSContext*, unsigned int, JS::Value*) (jsfun.cpp:1030) ==13469== by 0x9BE32AA: js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) (jscntxtinlines.h:220) ==13469== by 0x9BE052D: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (Interpreter.cpp:462) ==13469== by 0x9BE0FA9: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) (Interpreter.cpp:512) ==13469== by 0x9B24B6A: js::DirectProxyHandler::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jsproxy.cpp:454) ==13469== by 0x9B83919: js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jswrapper.cpp:454) ==13469== by 0x9B257D6: js::Proxy::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jsproxy.cpp:2643) ==13469== by 0x9B258F7: proxy_Call(JSContext*, unsigned int, JS::Value*) (jsproxy.cpp:3037) ==13469== by 0x9BE32AA: js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) (jscntxtinlines.h:220) ==13469== by 0x9BE052D: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (Interpreter.cpp:462) ==13469== by 0x9BD95BC: Interpret(JSContext*, js::RunState&) (Interpreter.cpp:2499) ==13469== by 0x9BE0308: js::RunScript(JSContext*, js::RunState&) (Interpreter.cpp:419) ==13469== by 0x9BE077A: js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) (Interpreter.cpp:481) ==13469== by 0x9BE0FA9: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) (Interpreter.cpp:512) ==13469== On paper, I track down the cause to the failure to initialize |mFirstNewDate|, a member of |nsNntpIncomingServer| class. For a new server, for which existing host inforamtion file is NOT read, this value is not initialized at all. Just search |mFirstNewDate| in comm-central using MXR. You will see what I mean. I think it ought to be initialized to some value. Question is, what value should it be? I suspect that uint32_t(PR_Now() / PR_USEC_PER_SEC); should be it, but I am not familiar with the code. Another choice would be 0: this means POSIX epoch (1970 Jan 1). Since TB currently writes out uninitialized bogus value (that can be a future date!) to the external file and seems to use that value forever, I think whichever value is better than the current undeterministic behavior: I prefer PR_now variant. TIA
Assignee | ||
Comment 1•11 years ago
|
||
I have no idea who the reviewer should be since the code in question has not been touched for quite some time. Also, I noticed that bug entry for product category, thunderbird, does not show "News" as component. I think this is wrong. "News" should be a valid entry (?) TIA
Assignee | ||
Comment 2•11 years ago
|
||
Comment on attachment 824770 [details] [diff] [review] Proposed patch: uses PR_now(). Back in 809060, it was Mark Banner who reviewed the patch, and so I am setting the reviewer to him. Still a mystery why this is caught now. Maybe a new test.
Attachment #824770 -
Flags: review?(mbanner)
Comment 3•11 years ago
|
||
Comment on attachment 824770 [details] [diff] [review] Proposed patch: uses PR_now(). So unless I'm mistaken, mFirstNewDate isn't actually used except when writing the file and is only filled in when reading the file. So really, it seems like it is redundant. Asking Joshua for a second opinion...
Attachment #824770 -
Flags: review?(mbanner) → review?(Pidgeot18)
Assignee | ||
Comment 4•11 years ago
|
||
(In reply to Mark Banner (:standard8) from comment #3) > Comment on attachment 824770 [details] [diff] [review] > Proposed patch: uses PR_now(). > > So unless I'm mistaken, mFirstNewDate isn't actually used except when > writing the file and is only filled in when reading the file. So really, it > seems like it is redundant. It looks like so unless JavaScript somehow access this and modifies it with XPCOM magic. > Asking Joshua for a second opinion... Appreciated. > On paper, I track down the cause to the failure to initialize > |mFirstNewDate|, a member of |nsNntpIncomingServer| class. With the patch posted here, I confirmed by |make mozill| run under valgrind/memcheck, that I can eliminate the error of using uninitialized value. So if JavaScript or some external entity tries to use the file and access the data, something like the posted patch should help. But now this is gone, another bug stands out: Bug 932851 - Use of uninitialized value created on stack: : js::Discard() (StructuredClone.cpp:351) (edit) TIA
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → ishikawa
Comment 5•11 years ago
|
||
(In reply to ISHIKAWA, Chiaki from comment #1) > I have no idea who the reviewer should be since the code in question has not > been touched for quite some time. > > Also, I noticed that bug entry for product category, thunderbird, does not > show "News" as component. I think this is wrong. "News" should be a valid > entry (?) > I think the Product should be "MailNews Core" and the Component "Networking: NNTP".
Assignee | ||
Comment 6•11 years ago
|
||
(In reply to Jens Müller (:tessarakt) from comment #5) > (In reply to ISHIKAWA, Chiaki from comment #1) > > I have no idea who the reviewer should be since the code in question has not > > been touched for quite some time. > > > > Also, I noticed that bug entry for product category, thunderbird, does not > > show "News" as component. I think this is wrong. "News" should be a valid > > entry (?) > > > > I think the Product should be "MailNews Core" and the Component "Networking: > NNTP". I tried to set the Product to MailNews Core, but then the component of "Networking: NNTP is now shown". I am afraid that the combination is not allowed by bugzilla? Hmm...
Assignee | ||
Updated•11 years ago
|
Component: Untriaged → Networking: NNTP
Product: Thunderbird → MailNews Core
Assignee | ||
Comment 7•11 years ago
|
||
I see. Once I change the Product to MailNews Core and tried to save the change, a new selection for component, version, etc. appeared! I wish the new component (MailNews Core) would have been shown when I changed the entry to MailNews Core even before saving it. Thanks for the product/component suggestion.
Comment 8•11 years ago
|
||
Comment on attachment 824770 [details] [diff] [review] Proposed patch: uses PR_now(). Review of attachment 824770 [details] [diff] [review]: ----------------------------------------------------------------- mFirstNewDate is otherwise unused, so it's better to kill it altogether instead of initializing it to a bad value. I believe this is meant to interoperate with NS 4.x hostinfo.dat files... but it's safe to say that no one cares about that interoperability anymore. :-)
Attachment #824770 -
Flags: review?(Pidgeot18) → review-
Assignee | ||
Comment 9•11 years ago
|
||
(In reply to Joshua Cranmer [:jcranmer] from comment #8) > Comment on attachment 824770 [details] [diff] [review] > Proposed patch: uses PR_now(). > > Review of attachment 824770 [details] [diff] [review]: > ----------------------------------------------------------------- > > mFirstNewDate is otherwise unused, so it's better to kill it altogether > instead of initializing it to a bad value. I believe this is meant to > interoperate with NS 4.x hostinfo.dat files... but it's safe to say that no > one cares about that interoperability anymore. :-) Thank you. I will create a patch that removes it completely. (I am still not sure why this showed up in my valgrind/memcheck lately. Maybe a new test triggered this code path???. But I digress.) TIA
Assignee | ||
Comment 10•11 years ago
|
||
This is a patch to eliminate the use of mFirstDate. I have not completely eradicate them, but instead turned the usage into comment. This is because there may be a chance that some developers notice the no-longer used "firstnewdate" line in existing external files (that are not used recently) and they may want to find out what is behind for that particular entry. At least, by leaving the comment lines, the developers would be able to find out "firstnewdate". TIA
Attachment #824770 -
Attachment is obsolete: true
Attachment #831404 -
Flags: review?(Pidgeot18)
Comment 12•10 years ago
|
||
It helps when asking review to ask from the right email address. :-)
Flags: needinfo?(Pidgeot18)
Comment 13•10 years ago
|
||
Comment on attachment 831404 [details] [diff] [review] A patch to eliminate mFirstDate. Review of attachment 831404 [details] [diff] [review]: ----------------------------------------------------------------- Don't comment it out, delete it entirely.
Attachment #831404 -
Flags: review?(Pidgeot18) → review-
Assignee | ||
Comment 14•10 years ago
|
||
(In reply to Joshua Cranmer [:jcranmer] from comment #12) > It helps when asking review to ask from the right email address. :-) Sorry, it still puzzles me sometimes to figure out what is one's correct e-mail address, and what is nickname (used in bugzilla). (In reply to Joshua Cranmer [:jcranmer] from comment #13) > Comment on attachment 831404 [details] [diff] [review] > A patch to eliminate mFirstDate. > > Review of attachment 831404 [details] [diff] [review]: > ----------------------------------------------------------------- > > Don't comment it out, delete it entirely. I am uploading a new patch here. TIA
Attachment #831404 -
Attachment is obsolete: true
Attachment #8358940 -
Flags: review?(Pidgeot18)
Comment 15•10 years ago
|
||
Comment on attachment 8358940 [details] [diff] [review] uninitialized-mFirstNewDate-Rev02.patch Review of attachment 8358940 [details] [diff] [review]: ----------------------------------------------------------------- ::: mailnews/news/src/nsNntpIncomingServer.h @@ +125,2 @@ > uint32_t mLastGroupDate; > + Nit: delete this blank line.
Attachment #8358940 -
Flags: review?(Pidgeot18) → review+
Assignee | ||
Comment 16•10 years ago
|
||
(In reply to Joshua Cranmer [:jcranmer] from comment #15) > Comment on attachment 8358940 [details] [diff] [review] > uninitialized-mFirstNewDate-Rev02.patch > > Review of attachment 8358940 [details] [diff] [review]: > ----------------------------------------------------------------- > > ::: mailnews/news/src/nsNntpIncomingServer.h > @@ +125,2 @@ > > uint32_t mLastGroupDate; > > + > > Nit: delete this blank line. Thank you for the review. I am uploading the final patch with the above whitespace line removed. I will put checkin-needed keyword.
Attachment #8358940 -
Attachment is obsolete: true
Attachment #8362184 -
Flags: review+
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Comment 17•10 years ago
|
||
https://hg.mozilla.org/comm-central/rev/59023e39e8a0
Status: NEW → RESOLVED
Closed: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 29.0
You need to log in
before you can comment on or make changes to this bug.
Description
•