replMain uses 1 cpu, ever-growing memory

[ericu]

I've been debugging on 0.7.0.4 using replMain, and I've noticed that 1) when my app is idle, it's using 100% of 1 cpu; 2) after a while, it locks up. I checked using top today, and I saw that it was using ever-increasing memory while I wasn't doing anything with it. Of course I first assumed it was my bug, but a profile showed all the time and allocations inside fltkhs, and switching FL.replRun to FL.run eliminated the problem entirely.

I do like using replRun for debugging, and I don't mind the CPU usage if it's necessary, but the memory leak limits its usefulness for any longer-term debugging sessions.

Problem [here UI takes a FilePath]: ui basePath >> FL.replRun

Solution: ui basePath >> FL.run >> FL.flush

Here's the relevant section of my profile:

replRun Graphics.UI.FLTK.LowLevel.FL src/Graphics/UI/FLTK/LowLevel/FL.chs:(1074,1)-(1089,45) 39050 0 0.6 5.9 100.0 99.8 waitFor Graphics.UI.FLTK.LowLevel.FL src/Graphics/UI/FLTK/LowLevel/FL.chs:(359,1)-(363,15) 39064 6740157 31.9 4.4 31.9 4.4 waitFor.\ Graphics.UI.FLTK.LowLevel.FL src/Graphics/UI/FLTK/LowLevel/FL.chs:(362,3)-(363,15) 39066 6740157 0.0 0.0 0.0 0.0 waitFor.a1' Graphics.UI.FLTK.LowLevel.FL src/Graphics/UI/FLTK/LowLevel/FL.chs:360:8-26 39065 6740157 0.0 0.0 0.0 0.0 firstWindow Graphics.UI.FLTK.LowLevel.FL src/Graphics/UI/FLTK/LowLevel/FL.chs:399:1-41 39055 0 0.2 0.0 35.9 86.6 toMaybeRef Graphics.UI.FLTK.LowLevel.Utils src/Graphics/UI/FLTK/LowLevel/Utils.hs:329:1-90 39059 6740158 0.3 5.9 3.1 79.3 toRef Graphics.UI.FLTK.LowLevel.Utils src/Graphics/UI/FLTK/LowLevel/Utils.hs:(298,1)-(302,35) 39061 6740157 0.2 5.9 2.8 73.4 throwStackOnError Graphics.UI.FLTK.LowLevel.Fl_Types src/Graphics/UI/FLTK/LowLevel/Fl_Types.chs:(441,1)-(445,47) 39062 6740157 0.4 8.8 2.6 67.5 wrapNonNull Graphics.UI.FLTK.LowLevel.Utils src/Graphics/UI/FLTK/LowLevel/Utils.hs:(164,1)-(169,57) 39063 6740157 2.2 58.7 2.2 58.7 firstWindow' Graphics.UI.FLTK.LowLevel.FL src/Graphics/UI/FLTK/LowLevel/FL.chs:(398,1)-(401,15) 39057 0 32.5 7.3 32.6 7.3 firstWindow'.\ Graphics.UI.FLTK.LowLevel.FL src/Graphics/UI/FLTK/LowLevel/FL.chs:(400,3)-(401,15) 39058 6740158 0.1 0.0 0.1 0.0 firstWindow'.\.res' Graphics.UI.FLTK.LowLevel.FL src/Graphics/UI/FLTK/LowLevel/FL.chs:400:8-20 39060 6740158 0.0 0.0 0.0 0.0 flush Graphics.UI.FLTK.LowLevel.FL src/Graphics/UI/FLTK/LowLevel/FL.chs:(396,1)-(399,15) 39052 0 31.6 2.9 31.6 2.9 flush.\ Graphics.UI.FLTK.LowLevel.FL src/Graphics/UI/FLTK/LowLevel/FL.chs:(398,3)-(399,15) 39053 6740158 0.0 0.0 0.0 0.0

Here's top after about a minute, with my app already up to 3.8 GB of memory and growing steadily: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13004 uranium 20 0 1.001t 3.814g 41036 R 100.7 12.4 1:04.21 server

[deech]

0.8.0.0 cleaned up a bunch of memory usage issues, hopefully this is one of them. I'll try to get the fixes to your issues in sometime this weekend or early next week. When I do would you be willing to test the master branch?

[ericu]

Sure thing. I may need to you to walk me through how to switch my build over; I've just done the bundled build so far, using stack. Thanks!

[deech]

I fixed the other issues but this one persists. I think I have an idea why but it'll be a couple of days.

[deech]

This should now be fixed. Do you mind testing? If you're happy with it I'll cut another release.

[ericu]

I'm happy to test it. How do I switch to master from the bundled version? I've just had stack build with 0.8.0.1, which does indeed fix my other problems, but appears to be before this fix.

[deech]

To test it you can do the following:

cd some-temp-direcory
git clone https://github.com/deech/fltkhs
cd your-project

In your stack.yaml change:

extra-deps:
  - fltkhs-0.8.0.1

to

packages:
  - '.'
  - '/path/to/some-temp-directory/fltkhs'

and then:

stack clean
rm -rf .stack-work
stack build --flag fltkhs:bundled

[ericu]

Looks like a partial fix. The memory leak is gone, but it still uses 100% of 1 CPU. That's not a biggie for me, since I've got spare cores, but clearly it's not ideal.

Oddly, it maxes out when I'm idle. When I try to keep my code busy, it immediately drops down by between 3 and 15%, depending on how much I can get it to do. I'm guessing the idle loop fully saturates the CPU, while actually doing something useful involves the occasional wait on IO or memory.

[deech]

Interesting, I'll take a look and make another issue for CPU usage. But since this fix gets you going I'm going to close the issue. Thanks for testing!

[ericu]

Incidentally, I was able to reproduce the CPU issue with master in fltkhs-hello-world, no modifications needed. Just call replMain from ghci and there it is.