Ticket #9 (closed defect: fixed)

Opened 11 years ago

Last modified 10 years ago

Memory leak

Reported by: cnicholsontech@… Owned by: dsmith
Priority: critical Milestone: Version 1.0
Component: wminput Version: 0.5.00
Keywords: memory leak Cc: 4.12

Description

wminput is pegging the memory hard, I have it running under Knoppmyth as my remote for MYthTV, and within about 30 minutes or so of initializing, it is taking up a lot of RAM. My system is a P4 1.4ghz with 384M ram and a 512M swap file, and under normal circumstances (read: w/o wminput) it rarely hits the swap file. Just now, wminput was using over 300M according to top. Then stuff started to die with out of memory errors.

cwiid 5.01

Change History

  Changed 11 years ago by dsmith

  • status changed from new to assigned

Yup - that's a problem. Can you post your configuration file (or just it's name if it's one included in CWiid).

  Changed 11 years ago by dsmith

  • priority changed from major to critical

follow-up: ↓ 4   Changed 11 years ago by cnicholsontech@…

Ok. I think I only changed the buttons file. Also, I don't have any sensor bar at the moment, I was only using this for the buttons. I picked up some crappy IR remotes and Ima chop'em up soon. I tried this mostly with just the wiimote, and once or twice with the nunchuck. I have a classic too, but haven't tried it.

<-- cut here -->

#acc_ptr

include buttons

Plugin.acc.X	= REL_X
Plugin.acc.Y	= REL_Y

-- buttons --
#buttons

Wiimote.A		= KEY_ENTER
Wiimote.B		= KEY_ESC
Wiimote.Up		= KEY_UP
Wiimote.Down	= KEY_DOWN
Wiimote.Left	= KEY_LEFT
Wiimote.Right	= KEY_RIGHT
Wiimote.Minus	= KEY_BACK
Wiimote.Plus	= KEY_FORWARD
Wiimote.Home	= KEY_P
Wiimote.1		= KEY_M
Wiimote.2		= KEY_I

Nunchuk.C		= BTN_LEFT
Nunchuk.Z		= BTN_RIGHT

Classic.Up		= KEY_UP
Classic.Down	= KEY_DOWN
Classic.Left	= KEY_LEFT
Classic.Right	= KEY_RIGHT
Classic.Minus	= KEY_BACK
Classic.Plus	= KEY_FORWARD
Classic.Home	= KEY_HOME
Classic.A		= BTN_LEFT
Classic.B		= BTN_RIGHT
#Classic.X		= 
#Classic.Y		= 
#Classic.ZL		= 
#Classic.ZR		= 
#Classic.L		= 
#Classic.R		= 

-- gamepad --
# gameport

Classic.Dpad.X = ABS_X
Classic.Dpad.Y = ABS_Y
Classic.LStick.X = ABS_HAT0X
Classic.LStick.Y = ABS_HAT0Y
Classic.RStick.X = ABS_HAT1X
Classic.RStick.Y = ABS_HAT1Y
Classic.A = BTN_A
Classic.B = BTN_B
Classic.X = BTN_X
Classic.Y = BTN_Y
Classic.Minus = BTN_SELECT
Classic.Plus  = BTN_START
Classic.Home  = BTN_MODE
Classic.L  = BTN_TL
Classic.R  = BTN_TR
Classic.ZL = BTN_TL2
Classic.ZR = BTN_TR2

-- ir port --
#ir_ptr

include buttons

Plugin.ir_ptr.X	= ~ABS_X
Plugin.ir_ptr.Y	= ~ABS_Y

-- neverball --
# neverball

Plugin.acc.Roll = ABS_X
Plugin.acc.Pitch = -ABS_Y

-- nunchuck acc ptr --
#nunchuk_acc_ptr

include buttons

Plugin.nunchuk_acc.X	= REL_X
Plugin.nunchuk_acc.Y	= REL_Y

in reply to: ↑ 3   Changed 11 years ago by dsmith

Sorry for the delay on this one.

Can anyone duplicate the error? I'm getting normal usage (0.1% mem usage, 1G RAM). Valgrind (see below) shows a few unfreed blocks, but no recurrent leaks. Perhaps the problem has been fixed (I'll revert to 0.5.01 tomorrow and try again)?

Does it eat memory for all config files? Also, can you tell me a bit more about the platform, specifically gcc and kernel version?

valgrind --tool=memcheck --leak-check=full --show-reachable=yes wminput
...
==13259== LEAK SUMMARY:
==13259==    definitely lost: 8 bytes in 3 blocks.
==13259==      possibly lost: 0 bytes in 0 blocks.
==13259==    still reachable: 1,696 bytes in 9 blocks.
==13259==         suppressed: 0 bytes in 0 blocks.

  Changed 11 years ago by dsmith

Was your battery low when this happened? I'm currently chatting with mokelmeister, he's running into the same problem with the battery at ~1%, as reported by wmgui.

  Changed 10 years ago by dsmith

I never could duplicate this error, but the most likely scenario I could think of (low battery throws something wacky in the Wiimote, which fires packets too rapidly for libcwiid to handle) should be handled by April's API overhaul (the pipes will fill up and error out, rather than adding message to an arbitrarily long queue).

Given the severity of the problem, I'll leave the ticket open for another week or so - if anyone can duplicate it with trunk or /branches/dev, please let us know.

  Changed 10 years ago by dsmith

  • status changed from assigned to closed
  • resolution set to fixed
Note: See TracTickets for help on using tickets.