Solved Displayed memory usage error in WebUI

[Maloon]

Hello,

Memory stats are not showed properly in webUI when a big SWAP file is used:

I hope this could be fixed.
Many thanks.

 

[octopus]

You have to provide more info about your environment.

 

[Maloon]

What do you want to know?

 

[Tech9]

when a big SWAP file is used

I don't see big swap file used on the screenshot. Reflash and reinstall to fix.

 

[Maloon]

10GB of swap. It is not too big, yes. But it is enough to see that memory stats are not showed properly. Reflashing did not fix anything. Issue is tested too with a RT-AX68U, with same result.

 

[Tech9]

What are you running on this poor router that needs 10GB swap?

 

[Maloon]

I personally don't consider that a RT-AX88U is a poor router.

 

[Tech9]

As Router - no. As something else - yes. What you torture the tiny router hardware with?

 

[ColinTaylor]

I can confirm this behaviour on my RT-AX86U. It looks like overflow issue in mem_stats_arr.

But in all honesty a 10GB swap file is too large. If you actually had processes running that used that amount of swap the router would grind to a standstill. Use something more reasonable like 2GB and the cosmetic error in the GUI will disappear. If you actually need 10GB of virtual memory I think you need to reevaluate what you're doing with the router.

 

[Maloon]

I was only reporting an issue. I don't need 10GB of swap, but it is better to have more than needed.

 

[Tech9]

but it is better to have more than needed.

Your hardware is less than needed, obviously. It's similar to already busy RPi with limited RAM.

 

[Maloon]

I know my hardware is more than needed, and hardware needs do not make sense with this issue, since it is a firmware issue and not a hardware issue.

 

[RMerlin]

I think I have a suspicion as to the cause.

Can you try running the following program on your router, and post the results?

test-swap

File

1drv.ms

Thanks.

 

[Maloon]

I think I have a suspicion as to the cause.

Can you try running the following program on your router, and post the results?

test-swap

File

1drv.ms

Thanks

Hello,

This is the result. It looks fine:

Many thanks.

 

[ColinTaylor]

By comparison, using a 1GB swap file gives:

# ./test-swap
unit_size: 1 - total swap: 1073737728

 

[RMerlin]

Hello,

This is the result. It looks fine:

View attachment 37773

Many thanks.

Ok, as I suspected. I need to multiply those values - it was the first time I saw mem_unit have a value different from 1.

 

[Maloon]

Ok, as I suspected. I need to multiply those values - it was the first time I saw mem_unit have a value different from 1.

Many thanks!

httpd: fix handling of memory values returned by sysinfo() for the To… · RMerl/asuswrt-merlin.ng@aac3e2a

…ols page

github.com

 

[ColinTaylor]

@RMerlin This is still not working on 386.4 / RT-AX86U.

Looks like the total size is being stored in a 32 bit variable and is overflowing.

With 5GB swap file:

# free
             total       used       free     shared    buffers     cached
Mem:        934032     903232      30800       2328        560     554236
-/+ buffers/cache:     348436     585596
Swap:      5242876          0    5242876

# cat /proc/meminfo | grep -i swap
SwapCached:            0 kB
SwapTotal:       5242876 kB
SwapFree:        5242876 kB

# /mnt/ClickUSB1/ASUS/test-swap
unit_size: 4096 - total swap: 1310719

 

[albinoman887]

i have the exact same issue as above. 2GB swapfile

 

[RMerlin]

Looks like the total size is being stored in a 32 bit variable and is overflowing.

It's not that simple, as I don't store it anywhere, it's directly manipulated as a float, and sent as text to the web page:

                        sprintf(result,"%.2f",(sys.totalswap * sys.mem_unit / (float)MBYTES));

The original bug was that the value wasn't multiplied by the unit size value (in your test, multiplying both values would give you 5 GB). If it still has issues reporting large values, then it's something else causing the whole calculation to fail (and it would be specific to ARM, as I couldn't reproduce the issue on a test case compiled for x86).