[Webkit-unassigned] [Bug 273662] New: Always log internal loader errors

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=273662

            Bug ID: 273662
           Summary: Always log internal loader errors
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Page Loading
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: mcatanzaro at redhat.com
                CC: beidson at apple.com, philn at igalia.com

Currently when WebKit encounters an internal error during loading, we release log a stacktrace showing the location of the error. However, there are several downsides:

 * Release stacktraces are generally very poor quality, so this is effectively useless
 * The stacktrace is only logged to the system journal, not to stderr, so it's unlikely to be noticed
 * I think it's only logged by default on Linux, because the journald implementation of WTFReleaseLogStackTrace ignores whether log channels are enabled
 * Otherwise, release logging has to be enabled manually (using the defaults database on macOS, or environment variables on Linux), so naturally it won't ever be enabled when needed

I'm pretty sure the failure to respect the log channel enablement is a bug in the Linux implementation of WTFReleaseLogStackTrace, but I don't think it's worth fixing because it's used from only two places: ResourceErrorBase.cpp, when logging an internal error, and PixelBufferConformerCV.cpp, which isn't built on Linux.

WebKit internal errors are bugs and worth printing more visibly. Let's always print an error message to stderr using WTFReportError so we have a better chance to debug it. This includes source file location to make it easier to see where the error is coming from; it's less precise than a good backtrace, but a lot better than a useless backtrace. Here is a sample of what this looks like for a fake error:

ERROR: WebKit encountered an internal error. This is a WebKit bug.
/home/mcatanzaro/Projects/WebKit/Source/WebKit/WebProcess/gtk/WebProcessMainGtk.cpp(75) : virtual bool WebKit::WebProcessMainGtk::platformInitialize()

Compare to the previous logging:

May 01 07:08:54 dreamyard WebKitWebProcess[8210]: 1   0x7f484818fce4 WTFGetBacktrace
May 01 07:08:54 dreamyard WebKitWebProcess[8210]: 2   0x7f484815f53c WTFReleaseLogStackTrace
May 01 07:08:54 dreamyard WebKitWebProcess[8210]: 3   0x7f484b2f654f /usr/lib/x86_64-linux-gnu/libwebkitgtk-6.0.so.4(+0x2af654f) [0x7f484b2f654f]
May 01 07:08:54 dreamyard WebKitWebProcess[8210]: 4   0x7f48495e82ea /usr/lib/x86_64-linux-gnu/libwebkitgtk-6.0.so.4(+0xde82ea) [0x7f48495e82ea]
May 01 07:08:54 dreamyard WebKitWebProcess[8210]: 5   0x7f48481f2915 /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-6.0.so.1(+0x15f2915) [0x7f48481f2915]
May 01 07:08:54 dreamyard WebKitWebProcess[8210]: 6   0x7f48481f1c61 /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-6.0.so.1(+0x15f1c61) [0x7f48481f1c61]
May 01 07:08:54 dreamyard WebKitWebProcess[8210]: 7   0x7f4844409767 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x60767) [0x7f4844409767]
May 01 07:08:54 dreamyard WebKitWebProcess[8210]: 8   0x7f484440b907 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x62907) [0x7f484440b907]
May 01 07:08:54 dreamyard WebKitWebProcess[8210]: 9   0x7f484440c3a7 g_main_loop_run
May 01 07:08:54 dreamyard WebKitWebProcess[8210]: 10  0x7f48481f2241 WTF::RunLoop::run()
May 01 07:08:54 dreamyard WebKitWebProcess[8210]: 11  0x7f48496c8b32 /usr/lib/x86_64-linux-gnu/libwebkitgtk-6.0.so.4(+0xec8b32) [0x7f48496c8b32]
May 01 07:08:54 dreamyard WebKitWebProcess[8210]: 12  0x7f484cecd08a /usr/lib/x86_64-linux-gnu/libc.so.6(+0x2808a) [0x7f484cecd08a]
May 01 07:08:54 dreamyard WebKitWebProcess[8210]: 13  0x7f484cecd14b __libc_start_main
May 01 07:08:54 dreamyard WebKitWebProcess[8210]: 14  0x55eabee2a085 /usr/libexec/webkitgtk-6.0/WebKitWebProcess(+0x1085) [0x55eabee2a085]

(This backtrace would be better if I had built with libbacktrace enabled, but no Linux distros do that because there are no releases of libbacktrace.)

Since there are no other remaining uses of RELEASE_LOG_BACKTRACE outside PixelBufferConformerCV.cpp, and since I don't like it, let's move the implementation to that file to discourage further use. This allows simplifying it to assume use of os_log.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20240503/1ad7960b/attachment-0001.htm>