Re: New and improved stack-fixing

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 cras

Re: New and improved stack-fixing

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 rem

Re: New and improved stack-fixing

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 op

Re: New and improved stack-fixing

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

Re: New and improved stack-fixing

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 dev-platf

Re: New and improved stack-fixing

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 is

Re: New and improved stack-fixing

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...

Re: New and improved stack-fixing

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 gets

Re: New and improved stack-fixing

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 + 0x5ab7

Re: New and improved stack-fixing

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: ??? > (

Re: New and improved stack-fixing

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... I

Re: New and improved stack-fixing

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 somethi

Re: New and improved stack-fixing

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 Nethercot

Re: New and improved stack-fixing

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 `au

Re: New and improved stack-fixing

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 refcoun

Re: New and improved stack-fixing

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 th

Re: New and improved stack-fixing

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 Ted's

Re: New and improved stack-fixing

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 desira

Re: New and improved stack-fixing

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 fu

Re: New and improved stack-fixing

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 sym

Re: New and improved stack-fixing

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 symbol

Re: New and improved stack-fixing

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 pa

Re: New and improved stack-fixing

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 stack-fixi

New and improved stack-fixing

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, bo