Bug 202196 – Don't try to use backtrace() on MIPS

• Status: RESOLVED
• Resolution: FIXED
• Component: Web Template Framework

[Guillaume Emont]

backtrace() on mips seems to always return 1 on mips/glibc (I tried with buildroot, debian stable and debian testing), which renders it useless and breaks a RELEASE_ASSERT in StackTrace::captureStackTrace().

[Guillaume Emont]

Created attachment 379535 [details]
Patch

Patch implementing this.

[Adrian Perez]

I have not checked glibc's code, but I expect that for code built
without frame pointers (the default for MIPS) it's always returning
an error because it's hard to walk the stack otherwise.

For binaries with .eh_frame sections, libunwind should work, but that
would still require building passing “-fasynchronous-unwind-tables”
to GCC. That might be an option if we want to bring back support for
backtraces on MIPS at some point.

Therefore, the patch is r=me, because plain backtrace() will be useless
99% of the time for MIPS.

[WebKit Commit Bot]

Comment on attachment 379535 [details]
Patch

Clearing flags on attachment: 379535

Committed r250516: <https://trac.webkit.org/changeset/250516>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/55835215>

[Guillaume Emont]

(In reply to Adrian Perez from comment #2)
> I have not checked glibc's code, but I expect that for code built
> without frame pointers (the default for MIPS) it's always returning
> an error because it's hard to walk the stack otherwise.
> 
> For binaries with .eh_frame sections, libunwind should work, but that
> would still require building passing “-fasynchronous-unwind-tables”
> to GCC. That might be an option if we want to bring back support for
> backtraces on MIPS at some point.
> 
> Therefore, the patch is r=me, because plain backtrace() will be useless
> 99% of the time for MIPS.

Thanks for explaining the reasons behind backtrace() being useless on MIPS. Note that technically, it's not returning an error (AFAIK the backtrace()'s API does not allow for that), but it's just giving a stack trace of size one (the current function), which confuses WTF code (even though it has code to ignore backtrace() if it returns 0, a return of 1 is not an expected failure case).