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)
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
| Reporter | ||
Comment 1•10 years ago
|
||
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
Comment 2•10 years ago
|
||
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)
| Reporter | ||
Comment 3•10 years ago
|
||
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
| Reporter | ||
Comment 4•10 years ago
|
||
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
Comment 5•10 years ago
|
||
> 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?
| Reporter | ||
Comment 6•10 years ago
|
||
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 :-)
| Reporter | ||
Comment 7•10 years ago
|
||
To clarify,
./mach run -P foo --no-remote 2>&1 | tools/rb/fix-linux-stack.py
ought to work in Bash and Bourne shell.
Comment 8•10 years ago
|
||
(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.
| Reporter | ||
Comment 9•10 years ago
|
||
(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.)
Updated•9 years ago
|
Component: Untriaged → General
Product: Core → Developer Documentation
Comment 10•9 years ago
|
||
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?
| Reporter | ||
Comment 11•9 years ago
|
||
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.
Comment 12•9 years ago
|
||
Ok, so the MDN part is fixed.
Note that wiki.mo being a wiki, you can fix it directly.
Updated•8 years ago
|
Component: General → Mozilla Platform
Comment 13•6 years ago
|
||
The MDN team is no longer actively working on Mozilla Platform docs. Volunteer contributions are welcome.
Priority: -- → P5
Comment 14•5 years ago
|
||
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.
Description
•