[Webkit-unassigned] [Bug 284963] New: WPEWebprocess running out of memory

[bugzilla-daemon at webkit.org]

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

            Bug ID: 284963
           Summary: WPEWebprocess running out of memory
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: Critical
          Priority: P2
         Component: New Bugs
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: himanshugaur2610 at gmail.com

Created attachment 473609

  --> https://bugs.webkit.org/attachment.cgi?id=473609&action=review

Apply 0001-debug-lws-memory-leak.patch to libwebsockets repo and rebuild. It allows to configure the ws period via /tmp/lws_period.txt and allow stopping/starting test-server without restarting webkit

Description: WPEWebprocess running out of memory causing cog to crash and display Out of Memory. Monitoring WPEWebProcess when running libwebsockets-test-server and starting cog at http://localhost:7681/ shows that the memory associated with the process kept on linearly increasing eventually causing a crash. 

Steps to Reproduce: 
start "libwebsockets-test-server"
start cog at "http://localhost:7681/"
Then you can stop/restart libwebsockets-test-server while leaving cog running to see if memory frees or not.

Actual Results: The whole browser presents a white screen with the error when it happens, and the journal log:
cog[19091]: Loaded successfully.
cog[19091]: Out of memory!: The renderer process ran out of memory. You may try reloading the page to restart it.

The application crashed.

Expected Results: The allocated memory associated with the WPEWebprocess should be freed periodically and should not linearly increase to crash the application.


Build Date & Hardware: This is consistently reproducible by just running this patch provided and happens on webkit version 2.44.4. 

Haven't seen this happening in 2.38.6 wpewebkit version.

Additional Information: Monitor and log resource usage:
Use system tools (e.g., top, htop, or specific memory profiling tools) to track memory consumption during these tests.

To reproduce this better, there is a patch that I have attached which can demonstrate this memory leak better.

Summary of the patch that helps to create the problem:
To increase the leak, apply 0001-debug-lws-memory-leak.patch to libwebsockets repo and rebuild. It allows to configure the ws period via /tmp/lws_period.txt and allow stopping/starting test-server without restarting webkit.

The following part only pertains to the patch and provides details about the same patch I have provided that can help reproduce this leak better:

This patch introduces several changes across two files: protocol_dumb_increment.c and test.js.
The main focus is to debug a memory leak in a WebSocket-based application by addressing the following key areas:

Changes to protocol_dumb_increment.c (WebSocket Protocol Handler)
Dynamic Period Adjustment:
The protocol_dumb_increment.c file has been modified to allow for dynamic adjustment of the "dumb increment period".
Previously, a fixed period (DUMB_PERIOD_US) was used, but now the period can be changed by writing a new value (in microseconds) to a file at /tmp/lws_period.txt. The change is read by the server when a WebSocket connection is established,
providing more flexibility to control the timing without modifying the code.
A new function get_period() was added, which checks for the value in /tmp/lws_period.txt. If the file exists and contains a valid value, it updates the period_us variable. This period is then passed to the lws_set_timer_usecs function, which is responsible for setting the timer period for the dumb increment protocol.

0001-debug-lws-memory-leak (1).patch:
The previous fixed DUMB_PERIOD_US was replaced by the dynamic value returned by get_period() during WebSocket connection setup and writes.

Changes to test.js (WebSocket Client)
Reconnect WebSocket on Lost Connection:
The client-side JavaScript was updated to improve how WebSocket connections are handled. Specifically, if the WebSocket connection (socket_di) is lost or closed, the script now attempts to reconnect automatically. This behavior is controlled via a setInterval that tries to reopen the WebSocket connection every second (1000ms).

Set up the environment:
Ensure that the server is running the patched version of the WebSocket server (protocol_dumb_increment.c) and that the client (test.js) is set up to connect to it.

Simulate WebSocket disconnection:
Initially open a WebSocket connection from the client. Then, simulate a WebSocket disconnect or close the connection manually (e.g., by disabling the network or closing the browser tab).

-- 
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/20241219/783c7eb8/attachment-0001.htm>