Each HTTP request makes mIRC use more RAM

[VitruxPT]

Hey,

Today I noticed that each HTTP request adds more ~0.1MB RAM which in a week or so, with all the requests my bot makes, it can get to around 500MB which is a ridiculous amount of RAM for an IRC interface! I'm not sure if this is a problem with mIRC or something about the JSON script that's causing this.

I've tested simply doing a JSON request while looking at the Task Manager and I can clearly see that it always adds ~0.1MB to the ram. Shouldn't this get free again once the request is done/script stops running, since (according to mIRC) all variables inside a script get destroyed once the script ends?

mIRC version: 7.48 (I'm also using /JSONClose and /JSONShutdown when the request ends)

[SReject]

The memory from an HTTP request should be getting freed once you close the JFM instance as there's no longer a reference to the HTTP requester(both inside mIRC and within the JS engine).

Assuming there is a bug in JFM, its most likely the JS garbage collector. I'll look into sorting that out.

[SReject]

@VitruxPT Now that I think about it, I need some more info:

1. Are you sure your mIRC version is correct? As there is a related memory leak in mIRC 7.47 that was fixed in 7.48: ref
2. What version of JFM are you using?
3. Is the reported memory usage specifically for mirc.exe

Can anyone else confirm/deny the constant rise in memory?

[VitruxPT]

1. Yes, it's 7.48 as showed in the image below.

2. I'm using the latest version available (1.0.4000)

3. Yes, this is only happening in mIRC, I double checked by using a fresh install of Windows Server 2012 R2 with only mIRC installed.

[SReject]

Whats the result of: //echo -a $version -- $jsonversion

Also, could you provide a short example script for me to test with as I'm not able to reproduce

[VitruxPT]

The result is:

Also screenshots after each request:

Code example:

alias example {
  JSONOpen example {"key": "value"}
  JSONClose example
}

[SReject]

Update - 01/16/18:

1. I've been able to confirm and reproduce the leak. I am now looking into the culprit but it may take quite a bit of time to figure out.

2. This doesn't affect JUST http requests, it affects all input methods.

[SReject]

Update - 01/20/18:

After spending quite a bit of time debugging, the good news is I've isolated the cause of the memory leak(1)... The bad news is that the cause is an integral part of the script.

The fix requires a near complete rewrite/work of both the JS and mSL code. I am currently working on doing just that but it will take time and may cause me to have to drop the path features.

(1): The cause is circular references, where parent has a reference to child and child has a reference to parent. Even though there's no outside reference to either, due to them referencing each other the memory is not freed.

[VitruxPT]

I'm glad you could find the problem, I just wasn't expecting it to be such a big one unfortunately. Take your time, I'll just keep closing and re-opening mIRC every week to make sure I don't run out of memory.

[SReject]

After a bit more debugging, part of the issue is mIRC's COM interface is leaking ontop of my JS leaking. I've reopened a bug report with mIRC so hopefully that gets fixed soon.

I am still going to rewrite/code the script to reduce the impact of the leak but I am not going to give a time frame of when the changes will be available.

[SReject]

Update - 01/21/18:

The latest mIRC beta (v7.51.1800) seems to have fixed the memory leak; at the least the majority of it.

It needs to be thoroughly tested with JFM to make sure he didn't break something as a side affect. Lemme know if bugs/odd behaviors are encountered

[VitruxPT]

Awesome, I'll let you know!