Thank you for the comment.
On 2022/04/22 19:53, Emilio Cobos Álvarez wrote:
On 4/22/22 09:22, ISHIKAWA,chiaki wrote:
Problem with C++/C macros is that most of the macros for debugging
purposes lack the notion of INFORMATIONAL messages. The macros are
about something went wrong, so abort with messages.: NS_ABORT,
NS_ASSERTION,
MOZ_ASSERT, etc.
something went wrong, so print an error message, but go on.
something seems fishy, so print a warning message, and go on.:
NS_WARNING, etc.
So this is only about debug asserts / warnings / NS_ENSURE_* macros,
right? Because MOZ_LOG does support a variety of log levels:
https://searchfox.org/mozilla-central/rev/6da1ebe13b260efabd88eb98dec5fa8ee65987b2/xpcom/base/Logging.h#62-69
Yes and no.
Yes, MOZ_LOG is a nice way to capture information from already
well-thought out processing.
However, can we use that on tryserver?
My point is that during development lots of macros are used by
programmers to leave a clue as to what could have possibly go wrong or
to obtain INFO-like data to guide the optimization.
For that purpose, we need to introduce macro for INFO.
Anyways, I agree that warnings that happen all the time should
probably not be warnings. I'd recommend just filing bug and ni?ing the
relevant developer if you're seeing super-spammy warnings in test logs.
I think Eric Rahm had a tool that used to keep track of this? Not sure
if somebody is maintaining / running that anymore, see:
https://bugzilla.mozilla.org/show_bug.cgi?id=765224
Interesting I already argued for macros for gathering INFO-like
information SEVEN (7) years ago in the bugzilla.
( My comment is https://bugzilla.mozilla.org/show_bug.cgi?id=765224#c6 )
We have not progressed much. :-(
[..]
Yes, (b) can be implemented locally by each developer to satisfy their
tastes for the local debug test runs, BUT I believe tryserver ought to
create a debug log file that would be meaningful for someone who sees
it for the first time.
(Well, I may be the only person in the world who regularly checks the
content of debug log file at least locally. Ugh...)
Not really. I check them very often at least. Using rr it's very easy
to basically replay the run, save the log to a file, and go to the
point of the program where the warning / message / test failure you
care about happens.
Hmm... Interesting. I have not used rr for TB testing before myself.
I wonder if rr tool is relevant for TB.
[..]
10 top most warnings coming from /libeditor/ during local mochitest
run of debug version of TB.
I suspect Thunderbird uses the editor much more heavily than Firefox,
so these aren't generally problems for most Gecko developers. If
they're causing trouble on Thunderbird, chances are you should look
into those, some of those look like potentially real bugs. Some others
seem like they can expectedly happen in some edge cases so maybe
NS_WARNING isn't quite warranted and that should be a MOZ_LOG or just
be silent.
I was under the impression that somebody would take care of the editor
mess. :-)
I mean I was explicitly told to stay away from these since they are in
M-C code. But I digress.
2947: Main Thread] WARNING: Scrolled rect smaller than scrollport?:
file
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/layout/generic/nsGfxScrollFrame.cpp:7154
This one I just sent a patch to remove.
Great to heart that. So this is not really a warning for a real problem. (?)
2164: Main Thread] WARNING: NS_ENSURE_TRUE(rootFrame) failed: file
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/dom/base/nsGlobalWindowOuter.cpp:4147
I see this on local Firefox startup too, and it's harmless:
https://bugzilla.mozilla.org/show_bug.cgi?id=1765961
I see.
Then this one is something I will remove by a local filtering tool somehow.
1659: Main Thread] WARNING: XPCOM object nsStringBuffer released from
static ctor/dtor: file
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/xpcom/base/nsTraceRefcnt.cpp:206
This one is probably something in Thunderbird having an `static
nsString` or so, should be fixed rather than the warning being
suppressed.
These warnings have been here for a long time.
Problem is that one of the file caching code in TB has a bug and it
triggers a crash randomly depending on the order of releases of ojbects
during final GC run just before the final exit.
When the crash happens, these ctor/dtor warnings are not printed because
TB has already crashed.
I have a patch to take care of the issue of this random crash and thus
see these ctor/dtor warnings all the time locally all the time.
Maybe others do not see these often (?)
The bug I have mentioned is
https://bugzilla.mozilla.org/show_bug.cgi?id=1677202
heap-use-after-free with C-C TB during shutdown,
nsMsgDBService::~nsMsgDBService()
The patch I posted averts the crash with educated guess of what data
left in the cash should be ignored because it is quite likely a bogus
pointer to an object already released.
'!ClientIsValidPrincipalInfo(mClientInfo.PrincipalInfo())', file
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/dom/clients/manager/ClientSource.cpp:183
This one seems like it should be investigated in comm-central. Seems
like it might be expected for some URIs? If it's harmless probably can
be turned into a log message.
Actually, when FF introduces Principal, etc. for coping with security
issues several years ago, TB developers were more or less at a loss what
it means for TB message streams, etc. since TB as far as I understand
does not grok javascript in HTML messages.
So probably Principal, etc. may not mean anything in TB.
But you are right, someone has to dig in deep to figure out what is
going on...
1011: Main Thread] WARNING: no request to cancel: file
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/mailnews/base/src/nsMsgProtocol.cpp:763
This one seems TB specific as well.
OK.
Cheers,
-- Emilio
Thank you very much for your comments, Emilio.
I will remove a few types of messages locally by filtering to see if
I can come up with an easier to deal with debug log file.
Also, your comments may prompt TB developers who are familiar with code
that produced the frequent messages to take a look.
Or maybe I am too optimistic.
Chiaki
--
You received this message because you are subscribed to the Google Groups
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/5b9bc739-0d22-a955-e79b-84892adb8bfc%40yk.rim.or.jp.
