Dear Nick,
I must have been doing something very stupid, but can't figure out
exactly.
I think after this change of fix-stack script(s), the local TB's
mochitest log's NS_ASSERTION (or is it MOZ_ASSERT?) stack trace cannot
be decoded.
I scratched my head and figured out that there is something wrong in
the stack trace of mochitest.
They look like this. I pick up the first stacktrace in the log.
0:21.30 GECKO(727384) {debug}:ASSERTION aISizeType=2, BTLS_FINALSIZE=2
0:21.30 GECKO(727384) aISize=0, guess_min=10203, guess_pref=10203
0:21.30 GECKO(727384) [727384, Main Thread] ###!!! ASSERTION: Table
inline-size is less than the sum of its columns' min inline-sizes:
'!(aISizeType == BTLS_FINAL_ISIZE && aISize < guess_min)', file
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/layout/tables/BasicTableLayoutStrategy.cpp,
line 767
Initializing stack-fixing for the first stack frame, this may take a
while...
0:28.61 INFO runtests.py | Waiting for browser...
0:28.98 GECKO(727384) #01: ???
(/NEW-SSD/moz-obj-dir/objdir-tb3/dist/bin/libxul.so + 0x5ab5921)
0:28.99 GECKO(727384) #02: ???
(/NEW-SSD/moz-obj-dir/objdir-tb3/dist/bin/libxul.so + 0x5ab7f34)
0:28.99 GECKO(727384) #03: ???
(/NEW-SSD/moz-obj-dir/objdir-tb3/dist/bin/libxul.so + 0x590de76)
0:28.99 GECKO(727384) #04: ???
(/NEW-SSD/moz-obj-dir/objdir-tb3/dist/bin/libxul.so + 0x5a94c2f)
0:28.99 GECKO(727384) #05: ???
(/NEW-SSD/moz-obj-dir/objdir-tb3/dist/bin/libxul.so + 0x5ab1589)
You can see the telltale sign of fix-stack being invoked.:
"Initializing stack-fixing for the first stack frame, this may take a
while..."
However, the stack is not decoded as you can see in the log.
The stack dump comes from the NS_ASSERTION() in the following.
I print out the strange value for debugging before NS_ASSERTION().
#ifdef DEBUG
if((aISizeType == BTLS_FINAL_ISIZE && aISize < guess_min)) {
fprintf(stderr,
"{debug}:ASSERTION aISizeType=%d, BTLS_FINALSIZE=%d\n",
aISizeType, BTLS_FINAL_ISIZE);
fprintf(stderr,"aISize=%d, guess_min=%d, guess_pref=%d\n",
aISize, guess_min, guess_pref);
}
#endif
NS_ASSERTION(!(aISizeType == BTLS_FINAL_ISIZE && aISize < guess_min),
"Table inline-size is less than the "
"sum of its columns' min inline-sizes");
if (aISize < guess_min_pct) {
Now, I look at fix_stacks.py and immediately noticed something strange
there.
The file is mozilla/tools/rb/fix_stacks.py.:
# Matches lines produced by MozFormatCodeAddress(), e.g.
# `#01: ???[tests/example +0x43a0]`.
line_re = re.compile("#\d+: .+\[.+ \+0x[0-9A-Fa-f]+\]")
You see the re (Regular Expression) does not match the line in
mochitest log produced by NS_ASSERTION().
What gives?
Also, another point is this.
I used to run the fix_linux_stack.py script AFTER the test was run and
log was recorded.
I fed the log to the script as its standard input and the script spit
out the decoded stack trace.
It no longer works this way even if I change line_re to match the
stack trace in mochitest log. Hmm...
Any idea re what went south?
TIA
Chiaki
On 2020/03/06 7:52, Nicholas Nethercote wrote:
Hi all,
I have written a new stack-fixing tool, called `fix-stacks`, which
symbolizes stack traces produced by Firefox.
`fix-stacks` is intended to replace our existing stack-fixing scripts,
`fix_{linux,macosx}_stack.py` and `fix_stack_using_bpsyms.py`, which are
used (a) on many test outputs, both locally and on automation, and
(b) by
DMD, Firefox's built-in heap profiler.
`fix-stacks` is now installed by `mach bootstrap` on Windows, Mac, and
Linux. It is usable from Python code via the `fix_stacks.py` wrapper
script. Its code is at https://github.com/mozilla/fix-stacks/.
In bug 1604095 I replaced the use of `fix_{linux,macosx}_stack.py` with
`fix_stacks.py` for DMD, with the following benefits.
* On Linux, stack-fixing of DMD output files (which occurs when you run
`dmd.py`) is roughly 100x faster. On my Linux box I saw reductions from
20-something minutes to ~13 seconds.
* On Mac, stack-fixing of DMD output files on Mac is roughly 10x
faster. On
my Mac laptop I saw reductions from ~7 minutes to ~45 seconds.
* On Windows, stack-fixing of DMD output files now occurs. (It
previously
did not because there is no `fix_window_stacks.py` script.) This
means that
DMD is now realistically usable on Windows without jumping through
hoops to
use breakpad symbols.
There is more work to be done. Soon, I plan to:
* use `fix-stacks` on test outputs (in `utils.py` and
`automation.py.in`);
* re-enable stack fixing on Mac test runs on local builds, which is
currently disabled because it is so slow;
* add breakpad symbol support to `fix-stacks`;
* remove the old scripts.
The tree of relevant bugs can be seen at
https://bugzilla.mozilla.org/showdependencytree.cgi?id=1596292&hide_resolved=1
.
The stack traces produced by `fix-stacks` are sometimes different to
those
produced by the old stack-fixers. In my experience these differences are
minor and you won't notice them if you aren't looking for them. But
let me
know if you have any problems.
Nick
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
