Closed Bug 1117536 Opened 10 years ago Closed 5 years ago

Documentation needs update: there is no longer fix-linux-stack.pl, but the file is now fix_linux_stack.py

Categories

(Developer Documentation Graveyard :: Mozilla Platform, defect, P5)

x86_64
Linux
defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: ishikawa, Unassigned)

Details

The script to convert numeric stack address in the stack backtrace printed by NS_ASSRTION, MOZ_ASSERT, etc. used to be available as fix-linux-stack.pl However, in the summer of 2014, it was replaced by a new file fix_linux_stack.py Furthurmore, while the former could take a file argument (as the first argument) to refer to the file that contains the stack backtrace, the latter only expects STDIN input stream to contain the stack backtrace. TIA
I should be more specific: the original comment went out prematurely. Searching, using google, "fix-linux-stack" site:.mozilla.org turned up following entries. (Almost all others in the first five pages are reference to bugzilla entries except for the following three.) case-I: https://developer.mozilla.org/ja/docs/XPCOM_DEBUG_BREAK Excerpt: stack - In addition to ringing the bell and printing a warning, a stack trace is written to stderr. Be sure to run the output through tools/rb/fix-macosx-stack.pl or tools/rb/fix-linux-stack.pl before sharing it. comment: obviously, fix-macosx-stack.pl should be changed to refer to fix_macosx_stack.py as well. Case-II: https://wiki.mozilla.org/Performance:Leak_Tools:DiffBloatDump Excerpt: Run ../tools/rb/fix-linux-stack.pl tmpfile > logoutput (or fix-macosx-stack.pl) comment: change the script name and change the usage: " < tmpfile" instead of "tmpfile". Case-III: https://wiki.mozilla.org/QA:Home_Page:Firefox_3.0_TestPlan:Leaks:Topsites Excerpt: With this Testrun we are also to log Memory Leaks and Assertions stack (using the fix-macos-stack.pl and fix-linux-stack.pl for Mac and Linux) into the Logfile. Case IV: https://wiki.mozilla.org/Sisyphus/Usage Excerpt: Contols whether debug dialogs, stacks or warnings are generated when an assertion occurs in the browser. If set to stack, and if fix-linux-stack.pl, fix-macosx-stack.pl are found on the PATH, they will be used to post process the logs to create Stacks containing symbols from the tested build. TIA
Isn't this "Developer Documentation" product? And/Or should be with dev-doc-needed keyword? Anyway, I'd be happy if somebody wrote how to use it. (required build options and simple command with ./mach run if it's possible)
Hi, Thank you for your comment. (In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) (offline: 5/2 - 5/6) from comment #2) > Isn't this "Developer Documentation" product? Yes, I was informed that these are Wiki pages which anyone (!) edit. > And/Or should be with > dev-doc-needed keyword? Anyway, I'd be happy if somebody wrote how to use > it. (required build options and simple command with ./mach run if it's > possible) I will update the Wiki pages myself. I did a modification the other day, and was surprised that I could log in to edit Wiki. I did not that and so in the future if I notice something amiss, I will edit the page. Once I am done with editing, I will close this entry. TIA
Hi, I was confused to no end when I tried editing. (In reply to ISHIKAWA, Chiaki from comment #1) > I should be more specific: the original comment went out prematurely. > > Searching, using google, > "fix-linux-stack" site:.mozilla.org > turned up following entries. (Almost all others in the first five pages are > reference to bugzilla entries except for the following three.) > > case-I: https://developer.mozilla.org/ja/docs/XPCOM_DEBUG_BREAK > Excerpt: stack - In addition to ringing the bell and printing a warning, a > stack trace is written to stderr. Be sure to run the output through > tools/rb/fix-macosx-stack.pl or tools/rb/fix-linux-stack.pl before sharing > it. > > comment: obviously, fix-macosx-stack.pl should be changed to refer to > fix_macosx_stack.py as well. Turns out that the particular URL I showed was somehow a Japanese translation page. I wanted to edit the ORIGINAL ENGLISH page. I am not entirely sure how I managed to navigate there. I think when I tried to change "/ja/" part in the URL with "/en/", I was redirected to https://developer.mozilla.org/en-US/docs/XPCOM_DEBUG_BREAK Note "/en-US/" in the URL. I am not that familiar with the particular "MD" (MarkDown) formating convention, but I managed to modify the essential there. If someone disagrees with the formating, be my guest and fix it. > > Case-II: > https://wiki.mozilla.org/Performance:Leak_Tools:DiffBloatDump > > Excerpt: > Run ../tools/rb/fix-linux-stack.pl tmpfile > logoutput (or > fix-macosx-stack.pl) > > comment: change the script name and change the usage: " < tmpfile" instead > of "tmpfile". This is getting ridiculous. I need to have a different login for this? I don't want to create such accounts without bound. I have enough already (can't recall some passwords myself...) So I simply write the replacement here and wonder if someone can fix this in the above URL. The last line in the main article CURRENT/INCORRECT: Run ../tools/rb/fix-linux-stack.pl tmpfile > logoutput (or fix-macosx-stack.pl) NEW/CORRECT: Run ../tools/rb/fix_linux_stack.py < tmpfile > logoutput (or fix_macosx_stack.py) > Case-III: > https://wiki.mozilla.org/QA:Home_Page:Firefox_3.0_TestPlan:Leaks:Topsites > > Excerpt: > With this Testrun we are also to log Memory Leaks and Assertions stack > (using the fix-macos-stack.pl and fix-linux-stack.pl for Mac and Linux) into > the Logfile. > The third paragraph in "Detail" section. CURRENT/INCORRECT: With this Testrun we are also to log Memory Leaks and Assertions stack (using the fix-macos-stack.pl and fix-linux-stack.pl for Mac and Linux) into the Logfile. NEW/CORRECT: With this Testrun we are also to log Memory Leaks and Assertions stack (using the fix_macos_stack.py and fix_linux_stack.py for Mac and Linux) into the Logfile. CI's comment: I doubt though whatever the planned code does the right thing is anyone's guess. This page was modified back in 2008 last time. > Case IV: > https://wiki.mozilla.org/Sisyphus/Usage > > Excerpt: > Contols whether debug dialogs, stacks or warnings are generated when an > assertion occurs in the browser. If set to stack, and if fix-linux-stack.pl, > fix-macosx-stack.pl are found on the PATH, they will be used to post process > the logs to create Stacks containing symbols from the tested build. > At the beginning of the last paragraph on the main article. CURRENT/INCORRECT: Contols whether debug dialogs, stacks or warnings are generated when an assertion occurs in the browser. If set to stack, and if fix-linux-stack.pl, fix-macosx-stack.pl are found on the PATH, they will be used to post process the logs to create Stacks containing symbols from the tested build. NEW/CORRECT: Contols whether debug dialogs, stacks or warnings are generated when an assertion occurs in the browser. If set to stack, and if fix_linux_stack.py, fix_macosx_stack.py are found on the PATH, they will be used to post process the logs to create Stacks containing symbols from the tested build. > TIA So whoever has an account in the wiki, please update the description. Thank you in advance. CI
> case-I: https://developer.mozilla.org/ja/docs/XPCOM_DEBUG_BREAK > Excerpt: stack - In addition to ringing the bell and printing a warning, a stack trace is written to stderr. Be sure to run the output through tools/rb/fix-macosx-stack.pl or tools/rb/fix-linux-stack.pl before sharing it. > > comment: obviously, fix-macosx-stack.pl should be changed to refer to fix_macosx_stack.py as well. Hmm, even if you just replace .pl with .py, the document is incorrect for now. I tried to get stacktrace with: ./mach run -P foo --no-remote | tools/rb/fix-linux-stack.py in the tree root directory and also ./firefox -P foo --no-remote | ./fix-linux-stack.py in the dist/bin directory. However, fix-linux-stack.py doesn't work with NS_ASSERTION() with XPCOM_DEBUG_BREAK=stack. However, it works with MOZ_CRASH(). So, I think that the output is stderr, but it seems that fix-linux-stack.py only checks stdin: http://mxr.mozilla.org/mozilla-central/source/tools/rb/fix_linux_stack.py#316 # A bug of the fix_linux_stack.py?
It is not the problem of *.py script, but more like the issue of directing STDERR output to STDOUT. Depending on the version of shell, this may or may not work. But whatever-program 2>&1 | ./fix-linux-stack.py ought to work in bash and modern Bourne Shell. If the following usage is suggested somewhere, it ought to be rewritten with the redirection of STDERR to STDOUT. > ./mach run -P foo --no-remote | tools/rb/fix-linux-stack.py But that needs the assumption about the user's shell. C-shell users are on their own :-)
To clarify, ./mach run -P foo --no-remote 2>&1 | tools/rb/fix-linux-stack.py ought to work in Bash and Bourne shell.
(In reply to ISHIKAWA, Chiaki from comment #7) > To clarify, > > ./mach run -P foo --no-remote 2>&1 | tools/rb/fix-linux-stack.py > > ought to work in Bash and Bourne shell. Thanks. That works.
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) (away: 7/27 - 8/2) from comment #8) > (In reply to ISHIKAWA, Chiaki from comment #7) > > To clarify, > > > > ./mach run -P foo --no-remote 2>&1 | tools/rb/fix-linux-stack.py > > > > ought to work in Bash and Bourne shell. > > Thanks. That works. You are welcome. (That one needs "2>&1" to make the above command line is a little inconvenient, but that is life.)
Component: Untriaged → General
Product: Core → Developer Documentation
Hi! I'm not able to determine from the discussion if the documentation is up-to-date or not? Is there still something to fix in the docs?
Current status. Referring to cases in comment 2: Case 1: somebody fixed it. Thanks. Case 2: No, old reference to .pl file is still there near the end of the page. case-3: not fixed yet. case-4: not fixed yet.
Ok, so the MDN part is fixed. Note that wiki.mo being a wiki, you can fix it directly.
Component: General → Mozilla Platform

The MDN team is no longer actively working on Mozilla Platform docs. Volunteer contributions are welcome.

Priority: -- → P5
MDN Web Docs' bug reporting has now moved to GitHub. From now on, please file content bugs at https://github.com/mdn/sprints/issues/ and platform bugs at https://github.com/mdn/kuma/issues/.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.