On Wed, 29 Apr 2020 at 02:32, ISHIKAWA,chiaki wrote:
>
> Ouch, I am using -gsplit-dwarf to make gdb startup time faster...
>
> -gsplit-dwarf is set manually on my bash script before invoking ./mach
> configure and build.
>
That would be the problem!
Do you think digging github of fix-stack
On 2020/04/28 18:13, Nicholas Nethercote wrote:
On Tue, 28 Apr 2020 at 17:50, ISHIKAWA,chiaki wrote:
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 +
As the author of one of these extensions for adding a custom search
engine
(https://addons.mozilla.org/en-US/firefox/addon/add-custom-search-engine/)
I am of course disappointed, but not actually surprised. This is
basically round two from about a year ago. I would like to point out
that it would
On Tue, 28 Apr 2020 at 17:50, ISHIKAWA,chiaki wrote:
>
> 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: ???
>
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...
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
6 matches
Mail list logo
