On 06/05/20 17:01, Markus Stange wrote:
> I see. What about crashes during regular optimized builds? I'd hope
> those print stacks.
You mean local builds? Unless you have ac_add_options --enable-debug in
your mozconfig you won't see stack traces. What you can do in that case
is build with the
On Wed, May 6, 2020 at 6:44 AM Gabriele Svelto wrote:
> On 05/05/20 23:38, Nicholas Nethercote wrote:
> > As for why that check is there... do opt builds produce any stack traces
> in
> > tests? Normal assertions aren't enabled on opt builds, but
> > diagnostic/release assertions are. I can't
On 05/05/20 23:38, Nicholas Nethercote wrote:
> As for why that check is there... do opt builds produce any stack traces in
> tests? Normal assertions aren't enabled on opt builds, but
> diagnostic/release assertions are. I can't remember off the top of my head
> if they produce stacks traces in
On Wed, 6 May 2020 at 07:22, Markus Stange wrote:
>
>
>> - On opt builds you won't get symbolication on any platform.
>>
>
> Are there plans to make this work? Does this apply to "optimized debug
> builds"?
>
This was in relation to tests, and it is due to this simple check
On Fri, Mar 6, 2020 at 12:13 AM Nicholas Nethercote
wrote:
> - On opt builds you won't get symbolication on any platform.
>
Are there plans to make this work? Does this apply to "optimized debug
builds"?
-Markus
___
dev-platform mailing list
Dear Nick,
Will my replacing fix-stacks binary with a binary to echo the input line
verbatim into the output
help me to obtain the original stack trace line?
I need to get the ORIGINAL line to see if I can get my interim script
based on linux-stack-fix.py to work
and understand the subtle
Thank you for the tips.
I will have a go to incorporate the logic of old fix_linux_stack.py into
fix-stacks.
TIA
Chiaki
On 2020/04/29 13:11, Nicholas Nethercote wrote:
On Wed, 29 Apr 2020 at 02:32, ISHIKAWA,chiaki wrote:
Ouch, I am using -gsplit-dwarf to make gdb startup time faster...
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 +
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
Thank you for the work you put in making this happen! I for one
certainly appreciate the results - stack symbolication used to be
pretty dodgy for me but now it seems fast and reliable!
On Tue, Apr 14, 2020 at 10:22 PM Nicholas Nethercote
wrote:
>
> On Fri, 6 Mar 2020 at 09:52, Nicholas
On Fri, 6 Mar 2020 at 09:52, Nicholas Nethercote
wrote:
>
> I have written a new stack-fixing tool, called `fix-stacks`, which
> symbolizes stack traces produced by Firefox.
>
> [...]
>
> There is more work to be done. Soon, I plan to:
>
> * use `fix-stacks` on test outputs (in `utils.py` and
No need to file a bug, I will fix this (and any other documentation I can
find) soon. Thanks for the link to this particular case.
Nick
On Fri, 13 Mar 2020 at 01:08, Chris Hutten-Czapski
wrote:
> This is wonderful news!
>
> The most recent time I interacted with this was tracking down a
This is wonderful news!
The most recent time I interacted with this was tracking down a refcount
leak. I was following the instructions at [1] which as of yet mention
`fix_linux_stack.py`.
Would you like me to file a bug for that to be fixed? I'd edit it directly,
but I'm not confident I'd get
On 06/03/20 16:46, Andrew Sutherland wrote:
> Thank you both very much for the clarifications and your excellent work
> here!
>
> In terms of the Sentry crates, I presume that means the crates in
> https://github.com/getsentry/symbolic repo? Are there still reasons to
> use/pay attention to
On 3/6/20 2:24 AM, Gabriele Svelto wrote:
Now for the long answer: we're leveraging the Sentry crates to replace
our current crash reporting machinery. Not only they're faster and
better than what we have now but their functionality is far richer. So
it will be possible - and possibly even
Thanks a lot for doing this work Nicholas.
I would like to add that once this hits automation the perf and memory
usage improvements will have a measurable impact on the tests runtime.
That's because we feed the output of all our tests on automation to the
scripts, and if they hit even a single
Hi Andrew,
On 06/03/2020 01:27, Andrew Sutherland wrote:
> Does this eliminate the need documented at
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Mochitest#stacks
> to acquire a `minidump_stackwalk` binary and then expose it via
> MINIDUMP_STACKWALK environment variable to get
On Fri, 6 Mar 2020 at 11:27, Andrew Sutherland
wrote:
> Does this eliminate the need documented at
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Mochitest#stacks
> to acquire a `minidump_stackwalk` binary and then expose it via
> MINIDUMP_STACKWALK environment variable to get
Does this eliminate the need documented at
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Mochitest#stacks
to acquire a `minidump_stackwalk` binary and then expose it via
MINIDUMP_STACKWALK environment variable to get symbolicated backtraces
when local test runs crash? Or is that
So excited to see this fixed - thank you Nick!
On Thu, Mar 5, 2020 at 2:52 PM 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
23 matches
Mail list logo
