Slimjet x64 Issues - Memory Leak & Crash on Activation Of Win. Explorer File Browser

Slimjet bug reports
Post Reply
Posts: 9
Joined: Sun Oct 02, 2016 6:29 pm

Slimjet x64 Issues - Memory Leak & Crash on Activation Of Win. Explorer File Browser

Post by stevekasian » Fri Aug 02, 2019 1:46 am


I am running Slimjet Version (based on Chromium 70.0.3538.67) (Official Build) (64-bit) on the following system:

Windows 7 Ultimate x64 SP1
Asus Crosshair V Formula
AMD FX-4170 Quad Core CPU - OC'd to 4.57GHz
8GB Corsair Vengeance DDR3 2000MHz CL10 RAM
Corsair Force 3 SSD SATA 6Gb/s
ESET NOD32 Antivirus
47 Running Processes

I have been noticing ever since switching to the x64 version (the past year or so) 2 specific recurring issues:

1. The browser eventually hogs up all system memory, then starts getting clunky (as there is no system memory left). When I notice this and close the browser, all running slimjet.exe processes remain running as the used memory is slowly released, mb by mb, by the "main" process... until it finally reaches 0 and the processes finally terminate. I can then restart Slimjet and select to restore my tabs that were open before the crash.

When this issue occurs, it is possible to manually terminate any of the slimjet.exe processes that are running EXCEPT for the "main" one that has hogged all the memory; That one cannot be terminated until it eventually releases all of the memory... at which time, it terminates itself.

2. Often times, when executing any function on a web page which performs a call to open a Windows Explorer file browser window (either to select a file to upload, or select a folder into which to download a file, for example), Slimjet will hang and eventually display a standard, non-skinned, "Windows" themed application bar at the top of the window (in place of the Slimjet themed bar). This will either remain for a 10 or 20 second period before it resumes normal operation, or it will permanently hang like this until the application is terminated via the (non-skinned) [X] in the upper right corner of the window. At that point, the application terminates immediately, then will offer the standard "restore previous tabs" option upon restart.

It is worth noting that the hang comes after selection of a file/folder, and after the Explorer file browser window closes... and that whatever file operation that was intended to take place (say a file upload or download) commences and runs in the background (i.e. If you're downloading a file and have selected a folder into which to save that file, the file data downloads in the background during the subsequent hang). However, that's as far as the "completion" of the file task goes; The file never gets properly processed and saved into the folder (or the file being uploaded never gets finalized, even though all of the file data gets uploaded to the server), unless it's the type of crash where the browser comes out of the hang automatically.

It is also worth noting that it matters not what disk is being "browsed" when this hang occurs (i.e. it is likely not a hardware issue, like a bad drive. I have around 5 or 6 drives active at any given time, and this hang occurs regardless of which drive is being accessed.)

It is also worth noting that, in each instance - Bug #1 and Bug #2, listed above - there is no crash dump file created (neither a browser_xx.dmp nor a render_xx.dmp file), so there is no info to be gleaned from the crash report folder.

Can anyone duplicate this bug other than me?

Last edited by oftentired on Fri Aug 02, 2019 6:22 pm, edited 1 time in total.
Reason: moved to Bug forum and 60 day sticky for visibility

Post Reply