Oh well, maybe this is a good opportunity to hear if anyone has an idea
whether the following warnings can be safely ignored, too.
Or to be more precise, if they can be removed from the code.
My script to summarize warnings/errors from log file could not be
updated soon enough since there have been so many new warnings, etc.
over the last few months and the following warnings (rather frequent,
note 5k+ warnings at the top) were not in the previous summary.
The issue is reported in
https://bugzilla.mozilla.org/show_bug.cgi?id=1691761#c3
And it seems to be safely ignored. If so, I would appreciate if someone
can create a patch to remove them.
I think my extraction routine was created on the fly and was not tested
extensively yet, so I see some strange
duplication (but strange count) with 'WARN' marker in the message. But
you get the idea.
grep webrender log1402-mochitest-13.txt | grep -v gfx.webrender.all |
cut -d " " -f 5- | sort | uniq -c | sort -n -k 1 -r
5425 webrender::renderer] asking to enable_gpu_markers but no
supporting extension was found
1171 webrender::device::gl] Missing optimized shader source for
gpu_cache_update
948 webrender::device::gl] Cropping texture upload Box2D((0, 0),
(0, 1)) to None
367 WARN webrender::renderer] asking to enable_gpu_markers but no
supporting extension was found
162 WARN webrender::device::gl] Cropping texture upload Box2D((0,
0), (0, 1)) to None
107 WARN webrender::device::gl] Missing optimized shader source
for gpu_cache_update
106 webrender::device::gl] Attribute VertexAttribute { name:
"aUvRect2", count: 4, kind: F32 } is not found in the shader composite.
Expected at 7, found at -1
[... omission ...]
TIA
Chiaki
On 2022/04/23 8:54, ISHIKAWA,chiaki wrote:
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
------------------------------------------
Thunderbird: Thunderbird Developers
Permalink:
https://thunderbird.topicbox.com/groups/developers/T320cf15a65f506c9-M5a099c6f56632d70bc1761bc
Delivery options:
https://thunderbird.topicbox.com/groups/developers/subscription
--
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/2cab88d0-8471-cc6a-b691-a0ae64f47e6a%40yk.rim.or.jp.
