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

NEW
Unassigned

Status

4 years ago
a year ago

People

(Reporter: ishikawa, Unassigned)

Tracking

Details

(Reporter)

Description

4 years ago
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

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

4 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

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

4 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

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

3 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

3 years ago
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?
(Reporter)

Comment 11

3 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.
Ok, so the MDN part is fixed.

Note that wiki.mo being a wiki, you can fix it directly.
Component: General → Mozilla Platform
You need to log in before you can comment on or make changes to this bug.