aMule Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

We're back! (IN POG FORM)

Pages: 1 ... 3 4 [5] 6 7 8

Author Topic: Re: upredictable memory leak  (Read 71801 times)

Kry

  • Ex-developer
  • Retired admin
  • Hero Member
  • *****
  • Karma: -665
  • Offline Offline
  • Posts: 5795
Re: Re: upredictable memory leak
« Reply #60 on: January 15, 2011, 12:58:29 AM »
I am having an awesome weekend, but I will go back home monday and check this out.


Promise.
Logged

btkaos

  • Global Moderator
  • Sr. Member
  • *****
  • Karma: 110
  • Offline Offline
  • Posts: 486
  • Kaos is infinite!
Re: upredictable memory leak
« Reply #61 on: January 15, 2011, 01:07:05 AM »
Just a note, wxSockets in svn is very different than it is now, although it seems to suffer from the same problem

Kry, it may be a wxWidget bug or an amule bug, depends on whether it is fixable from amule.

I'd say it is not going to be fixable from within aMule, of course I'm not sure at all. Given the state of wx svn writing a patch may prove difficult until wx change rate slows down.
Logged

btkaos

  • Global Moderator
  • Sr. Member
  • *****
  • Karma: 110
  • Offline Offline
  • Posts: 486
  • Kaos is infinite!
Re: upredictable memory leak
« Reply #62 on: January 15, 2011, 02:06:50 AM »
More info for debug. I modified wx event handler to print once a second if it is called. You can see the moment it is never called back.
The other output is all the EMSocket we have with the first number being the download limit of the socket, between braces the number of events the socket has pending.
Code: [Select]
0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 2 [0] 14 [0] 0 [0] 1024 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 1024 [0] 0 [0] 10 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 32 [0] 0 [0] 49 [0] 27 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 54 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 79 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 1024 [0] 0 [0] 1024 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] 0 [0] ---------------------------------------------------
wx event Callback!!!
wx event Callback!!!
wx event Callback!!!
0 [0] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 2 [1] 13 [1] 0 [1] 1024 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 1024 [1] 0 [1] 10 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 31 [1] 0 [1] 49 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 75 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 1024 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] 0 [1] ---------------------------------------------------
TEVS 164
wx event Callback!!!
wx event Callback!!!
0 [0] 0 [66470] 0 [66470] 0 [66470] 0 [66470] 0 [66472] 0 [66472] 2 [66472] 13 [66472] 0 [66474] 1024 [66474] 0 [66474] 0 [66474] 0 [66476] 0 [66476] 0 [66476] 0 [66476] 0 [66478] 0 [66478] 0 [66478] 0 [66478] 0 [66480] 0 [66480] 0 [66480] 0 [66480] 1024 [66482] 0 [66482] 10 [66482] 0 [66482] 0 [66484] 0 [66484] 0 [66484] 0 [66484] 31 [66486] 0 [66486] 49 [66486] 0 [66486] 0 [66488] 0 [66488] 0 [66490] 0 [66490] 0 [66490] 0 [66490] 0 [66492] 0 [66492] 0 [66492] 0 [66492] 0 [66494] 0 [66494] 0 [66494] 0 [66494] 0 [66494] 0 [66496] 0 [66496] 0 [66496] 0 [66496] 0 [66496] 0 [66498] 0 [66498] 0 [66498] 0 [66498] 0 [66498] 0 [66500] 0 [66500] 0 [66500] 0 [66500] 0 [66502] 0 [66502] 0 [66502] 0 [66502] 0 [66504] 0 [66504] 0 [66504] 0 [66504] 0 [66506] 0 [66506] 0 [66506] 0 [66506] 0 [66507] 0 [66508] 0 [66508] 0 [66508] 0 [66509] 0 [66510] 0 [66510] 0 [66510] 0 [66511] 0 [66512] 0 [66512] 0 [66512] 0 [66513] 0 [66514] 0 [66514] 0 [66514] 0 [66515] 0 [66516] 0 [66516] 0 [66516] 0 [66517] 0 [66518] 0 [66518] 0 [66518] 0 [66519] 0 [66520] 0 [66520] 0 [66520] 0 [66521] 0 [66522] 0 [66522] 0 [66522] 0 [66523] 0 [66524] 0 [66524] 0 [66524] 0 [66524] 0 [66526] 0 [66526] 0 [66526] 0 [66526] 0 [66528] 0 [66528] 0 [66528] 0 [66528] 0 [66530] 0 [66530] 0 [66530] 0 [66530] 0 [66532] 0 [66532] 0 [66532] 0 [66533] 0 [66534] 0 [66534] 0 [66534] 0 [66535] 0 [66536] 0 [66536] 0 [66536] 0 [66537] 0 [66538] 0 [66538] 1024 [66538] 0 [66539] 0 [66540] 0 [66540] 0 [66540] 0 [66541] 0 [66542] 0 [66542] 0 [66542] 0 [66542] 0 [66544] 0 [66544] 0 [66544] 0 [66544] 0 [66545] 0 [66546] 0 [66546] 0 [66546] 0 [66547] 0 [66548] 0 [66548] 0 [66548] 0 [66549] 0 [66550] 0 [66550] 0 [66550] 0 [66551] 0 [66552] 0 [66552] 0 [66552] 0 [66553] 0 [66554] 0 [66554] 0 [66554] 0 [66555] 0 [66556] ---------------------------------------------------
TEVS 11697450
0 [0] 0 [434748] 0 [434749] 0 [434752] 0 [434752] 0 [434753] 0 [434756] 2 [434756] 13 [434756] 0 [434760] 1024 [434760] 0 [434760] 0 [434764] 0 [434764] 0 [434764] 0 [434766] 0 [434768] 0 [434768] 0 [434770] 0 [434772] 0 [434772] 0 [434773] 0 [434776] 0 [434776] 0 [434776] 1024 [434777] 0 [434780] 10 [434780] 0 [434780] 0 [434783] 0 [434784] 0 [434784] 0 [434784] 31 [434788] 0 [434788] 49 [434788] 0 [434792] 0 [434792] 0 [434792] 0 [434796] 0 [434796] 0 [434796] 0 [434800] 0 [434800] 0 [434800] 0 [434802] 0 [434804] 0 [434804] 0 [434804] 0 [434808] 0 [434808] 0 [434808] 0 [434812] 0 [434812] 0 [434812] 0 [434816] 0 [434816] 0 [434816] 0 [434819] 0 [434820] 0 [434820] 0 [434821] 0 [434824] 0 [434824] 0 [434828] 0 [434828] 0 [434828] 0 [434832] 0 [434832] 0 [434832] 0 [434836] 0 [434836] 0 [434836] 0 [434838] 0 [434840] 0 [434840] 0 [434840] 0 [434844] 0 [434844] 0 [434844] 0 [434848] 0 [434848] 0 [434848] 0 [434852] 0 [434852] 0 [434852] 0 [434855] 0 [434856] 0 [434856] 0 [434857] 0 [434860] 0 [434860] 0 [434860] 0 [434864] 0 [434864] 0 [434864] 0 [434868] 0 [434868] 0 [434868] 0 [434872] 0 [434872] 0 [434872] 0 [434874] 0 [434876] 0 [434876] 0 [434876] 0 [434880] 0 [434880] 0 [434880] 0 [434884] 0 [434884] 0 [434884] 0 [434888] 0 [434888] 0 [434888] 0 [434892] 0 [434892] 0 [434892] 0 [434892] 0 [434896] 0 [434896] 0 [434896] 0 [434900] 0 [434900] 0 [434900] 0 [434904] 0 [434904] 0 [434904] 0 [434908] 0 [434908] 0 [434908] 0 [434910] 0 [434912] 0 [434912] 0 [434912] 0 [434916] 0 [434916] 0 [434916] 0 [434920] 0 [434920] 0 [434920] 1024 [434924] 0 [434924] 0 [434924] 0 [434928] 0 [434928] 0 [434928] 0 [434929] 0 [434932] 0 [434932] 0 [434932] 0 [434936] 0 [434936] 0 [434936] 0 [434940] 0 [434940] 0 [434940] 0 [434944] 0 [434944] 0 [434944] 0 [434946] 0 [434948] 0 [434948] 0 [434948] 0 [434952] 0 [434952] 0 [434952] 0 [434956] 0 [434956] 0 [434956] 0 [434960] 0 [434960] 0 [434960] 0 [434964] 0 [434964] 0 [434964] 0 [434965] ---------------------------------------------------
TEVS 76513101
0 [0] 0 [1139230] 0 [1139230] 0 [1139235] 0 [1139241] 0 [1139241] 0 [1139241] 2 [1139246] 13 [1139252] 0 [1139252] 1024 [1139252] 0 [1139256] 0 [1139263] 0 [1139263] 0 [1139263] 0 [1139267] 0 [1139273] 0 [1139274] 0 [1139274] 0 [1139276] 0 [1139284] 0 [1139285] 0 [1139285] 0 [1139288] 0 [1139292] 1024 [1139296] 0 [1139296] 10 [1139296] 0 [1139303] 0 [1139307] 0 [1139307] 0 [1139307] 0 [1139312] 31 [1139318] 0 [1139318] 49 [1139318] 0 [1139324] 0 [1139329] 0 [1139329] 0 [1139329] 0 [1139332] 0 [1139340] 0 [1139340] 0 [1139340] 0 [1139344] 0 [1139350] 0 [1139351] 0 [1139351] 0 [1139353] 0 [1139361] 0 [1139362] 0 [1139362] 0 [1139363] 0 [1139370] 0 [1139373] 0 [1139373] 0 [1139374] 0 [1139381] 0 [1139384] 0 [1139384] 0 [1139384] 0 [1139390] 0 [1139395] 0 [1139395] 0 [1139395] 0 [1139397] 0 [1139403] 0 [1139406] 0 [1139406] 0 [1139407] 0 [1139415] 0 [1139417] 0 [1139417] 0 [1139418] 0 [1139424] 0 [1139428] 0 [1139428] 0 [1139428] 0 [1139435] 0 [1139439] 0 [1139439] 0 [1139439] 0 [1139445] 0 [1139450] 0 [1139450] 0 [1139450] 0 [1139454] 0 [1139461] 0 [1139461] 0 [1139461] 0 [1139466] 0 [1139472] 0 [1139472] 0 [1139472] 0 [1139475] 0 [1139483] 0 [1139483] 0 [1139483] 0 [1139486] 0 [1139491] 0 [1139494] 0 [1139494] 0 [1139494] 0 [1139502] 0 [1139505] 0 [1139505] 0 [1139506] 0 [1139511] 0 [1139516] 0 [1139516] 0 [1139516] 0 [1139522] 0 [1139527] 0 [1139527] 0 [1139527] 0 [1139531] 0 [1139538] 0 [1139538] 0 [1139538] 0 [1139543] 0 [1139548] 0 [1139549] 0 [1139549] 0 [1139552] 0 [1139560] 0 [1139560] 0 [1139560] 0 [1139563] 0 [1139569] 0 [1139571] 0 [1139571] 0 [1139572] 0 [1139581] 0 [1139582] 0 [1139582] 0 [1139582] 0 [1139590] 0 [1139593] 0 [1139593] 0 [1139593] 0 [1139600] 1024 [1139604] 0 [1139604] 0 [1139604] 0 [1139610] 0 [1139615] 0 [1139615] 0 [1139615] 0 [1139620] 0 [1139626] 0 [1139626] 0 [1139626] 0 [1139631] 0 [1139637] 0 [1139637] 0 [1139637] 0 [1139641] 0 [1139648] 0 [1139648] 0 [1139648] 0 [1139652] 0 [1139659] 0 [1139659] 0 [1139661] 0 [1139669] 0 [1139670] 0 [1139670] 0 [1139672] 0 [1139678] 0 [1139681] 0 [1139681] 0 [1139682] 0 [1139690] 0 [1139692] 0 [1139692] 0 [1139692] 0 [1139699] ---------------------------------------------------
TEVS 200497642
0 [0] 0 [2220620] 0 [2220621] 0 [2220626] 0 [2220633] 0 [2220637] 0 [2220639] 2 [2220639] 13 [2220639] 0 [2220647] 1024 [2220654] 0 [2220658] 0 [2220658] 0 [2220658] 0 [2220666] 0 [2220672] 0 [2220677] 0 [2220677] 0 [2220677] 0 [2220685] 0 [2220691] 0 [2220696] 0 [2220696] 0 [2220696] 0 [2220703] 1024 [2220709] 0 [2220715] 10 [2220715] 0 [2220715] 0 [2220722] 0 [2220728] 0 [2220734] 0 [2220734] 31 [2220734] 0 [2220740] 49 [2220746] 0 [2220753] 0 [2220753] 0 [2220753] 0 [2220759] 0 [2220765] 0 [2220772] 0 [2220772] 0 [2220772] 0 [2220777] 0 [2220782] 0 [2220790] 0 [2220791] 0 [2220791] 0 [2220795] 0 [2220801] 0 [2220809] 0 [2220810] 0 [2220810] 0 [2220813] 0 [2220819] 0 [2220827] 0 [2220829] 0 [2220829] 0 [2220832] 0 [2220838] 0 [2220846] 0 [2220848] 0 [2220848] 0 [2220850] 0 [2220856] 0 [2220865] 0 [2220867] 0 [2220867] 0 [2220869] 0 [2220875] 0 [2220884] 0 [2220886] 0 [2220886] 0 [2220886] 0 [2220889] 0 [2220895] 0 [2220903] 0 [2220905] 0 [2220905] 0 [2220907] 0 [2220913] 0 [2220922] 0 [2220924] 0 [2220924] 0 [2220926] 0 [2220932] 0 [2220940] 0 [2220943] 0 [2220943] 0 [2220944] 0 [2220950] 0 [2220959] 0 [2220962] 0 [2220962] 0 [2220963] 0 [2220969] 0 [2220978] 0 [2220981] 0 [2220981] 0 [2220982] 0 [2220988] 0 [2220997] 0 [2221000] 0 [2221000] 0 [2221000] 0 [2221007] 0 [2221015] 0 [2221019] 0 [2221019] 0 [2221019] 0 [2221026] 0 [2221034] 0 [2221038] 0 [2221038] 0 [2221038] 0 [2221043] 0 [2221051] 0 [2221057] 0 [2221057] 0 [2221057] 0 [2221061] 0 [2221070] 0 [2221076] 0 [2221076] 0 [2221076] 0 [2221080] 0 [2221088] 0 [2221094] 0 [2221095] 0 [2221095] 0 [2221099] 0 [2221107] 0 [2221111] 0 [2221114] 0 [2221114] 0 [2221116] 0 [2221124] 0 [2221130] 0 [2221133] 0 [2221133] 1024 [2221135] 0 [2221143] 0 [2221147] 0 [2221152] 0 [2221152] 0 [2221152] 0 [2221160] 0 [2221166] 0 [2221171] 0 [2221171] 0 [2221171] 0 [2221179] 0 [2221185] 0 [2221190] 0 [2221190] 0 [2221190] 0 [2221198] 0 [2221204] 0 [2221209] 0 [2221209] 0 [2221209] 0 [2221217] 0 [2221223] 0 [2221228] 0 [2221228] 0 [2221228] 0 [2221236] 0 [2221242] 0 [2221247] 0 [2221247] 0 [2221247] 0 [2221255] 0 [2221261] 0 [2221266] 0 [2221266] 0 [2221266] ---------------------------------------------------
TEVS 390822299
All this is weird. But at least you may see where the memory is spent and when wx event handling is starved.

Below is a backtrace of event creation. How silly it calls WakeUpIdle! You can see that the cause is GDK_INPUT_WRITE event.
Code: [Select]
(gdb) bt
#0  0x00007ffff67da26c in wxApp::WakeUpIdle (this=0x7ffff602465d) at ./src/gtk/app.cpp:139
#1  0x00007ffff602465d in wxWakeUpIdle () at ./src/common/appbase.cpp:647
#2  0x00007ffff60e0f69 in wxEvtHandler::AddPendingEvent (this=0xc1e620, event=...) at ./src/common/event.cpp:1164
#3  0x00007ffff63bdb40 in wxSocketBase::OnRequest (this=0x1a1d8f0, notification=wxSOCKET_OUTPUT) at ./src/common/socket.cpp:1006
#4  0x00007ffff63bd94f in wx_socket_callback (notification=GSOCK_OUTPUT, cdata=0x1a1d8f0 "\260Xv") at ./src/common/socket.cpp:942
#5  0x00007ffff63c4323 in GSocket::Detected_Write (this=0x1a1df60) at ./src/unix/gsocket.cpp:1836
#6  0x00007ffff67fcb1c in _GSocket_GDK_Input (data=0x1a1df60, source=65, condition=GDK_INPUT_WRITE) at ./src/gtk/gsockgtk.cpp:41
#7  0x00007ffff478e99f in gdk_io_invoke (source=<value optimized out>, condition=<value optimized out>, data=<value optimized out>)
    at /build/buildd/gtk+2.0-2.22.0/gdk/gdkevents.c:1082
#8  0x00007ffff29d0342 in g_main_dispatch (context=0xc67f10) at /build/buildd/glib2.0-2.26.1/glib/gmain.c:2149
#9  g_main_context_dispatch (context=0xc67f10) at /build/buildd/glib2.0-2.26.1/glib/gmain.c:2702
#10 0x00007ffff29d42a8 in g_main_context_iterate (context=0xc67f10, block=<value optimized out>, dispatch=<value optimized out>,
    self=<value optimized out>) at /build/buildd/glib2.0-2.26.1/glib/gmain.c:2780
#11 0x00007ffff29d47b5 in g_main_loop_run (loop=0x1681110) at /build/buildd/glib2.0-2.26.1/glib/gmain.c:2988
#12 0x00007ffff4b4d3e7 in IA__gtk_main () at /build/buildd/gtk+2.0-2.22.0/gtk/gtkmain.c:1237
#13 0x00007ffff67fab5f in wxEventLoop::Run (this=0x167f110) at ./src/gtk/evtloop.cpp:76
#14 0x00007ffff6896dc8 in wxAppBase::MainLoop (this=0xc67970) at ./src/common/appcmn.cpp:312
#15 0x00007ffff6896f42 in wxAppBase::OnRun (this=0xc67970) at ./src/common/appcmn.cpp:367
#16 0x00007ffff606ae5b in wxEntry (argc=@0x7ffff638f4b0, argv=0xc56e10) at ./src/common/init.cpp:448
#17 0x00007ffff606af31 in wxEntry (argc=@0x7fffffffe0bc, argv=0x7fffffffe1a8) at ./src/common/init.cpp:460
#18 0x00000000005d0b82 in main (argc=1, argv=0x0) at amule-gui.cpp:93
Just a note, aMule is running, just stopped in gdb
 
Code: [Select]
0  1000  3592  3590  20   0 2892712 2623280 ptrace tl pts/1     1:33 /usr/local/bin/amule
Logged

btkaos

  • Global Moderator
  • Sr. Member
  • *****
  • Karma: 110
  • Offline Offline
  • Posts: 486
  • Kaos is infinite!
Re: upredictable memory leak
« Reply #63 on: January 15, 2011, 02:09:43 AM »
LOG analysis, for some reason, it seems like glib went crazy and started firing events without control.

Ops, I forgot, download limit is set to 10Kbps.
Logged

btkaos

  • Global Moderator
  • Sr. Member
  • *****
  • Karma: 110
  • Offline Offline
  • Posts: 486
  • Kaos is infinite!
Re: upredictable memory leak
« Reply #64 on: January 15, 2011, 02:51:29 AM »
My patches to wx-2.8.11 and amule in case anyone wants to investigate.
Logged

Stu Redman

  • Administrator
  • Hero Member
  • *****
  • Karma: 214
  • Offline Offline
  • Posts: 3739
  • Engines screaming
Re: upredictable memory leak
« Reply #65 on: January 15, 2011, 03:12:34 PM »
Quote from: btkaos on January 14, 2011, 11:16:54 PM
BTW, the patch doesn't work :(

I have modified your patch, please retry.
I have changed the way events are reenabled and added a flag for events disabled, that's the part that counts. The socket counting is also in the patch. You can keep your other debug stuff of course.
Logged
The image of mother goddess, lying dormant in the eyes of the dead, the sheaf of the corn is broken, end the harvest, throw the dead on the pyre -- Iron Maiden, Isle of Avalon

btkaos

  • Global Moderator
  • Sr. Member
  • *****
  • Karma: 110
  • Offline Offline
  • Posts: 486
  • Kaos is infinite!
Re: upredictable memory leak
« Reply #66 on: January 17, 2011, 04:28:33 PM »
Ok trying the patch, however I don't yet understand fully how the download limiting works. I guess I disabled the events in the wrong place.

Note that this seems like it should be fixed in wxwidgets, waiting for them to finish the overhaul and i'll send a bug.
Logged

btkaos

  • Global Moderator
  • Sr. Member
  • *****
  • Karma: 110
  • Offline Offline
  • Posts: 486
  • Kaos is infinite!
Re: upredictable memory leak
« Reply #67 on: January 17, 2011, 05:43:12 PM »
With your patch again a corrupted context, damm glib this should never happen. Anyways I did see some interesting things, but I have to double check them.

Code: [Select]
(gdb) bt
#0  __pthread_mutex_lock (mutex=0x7) at pthread_mutex_lock.c:50
#1  0x00007ffff29d004f in g_source_destroy_internal (source=0x7fffdc2fe130, context=0xffffffffffffffff, have_lock=0)
    at /build/buildd/glib2.0-2.26.1/glib/gmain.c:942
#2  0x00007ffff29d290e in g_source_remove (tag=<value optimized out>) at /build/buildd/glib2.0-2.26.1/glib/gmain.c:1717
#3  0x00007ffff67fcc7d in GSocketGUIFunctionsTableConcrete::Uninstall_Callback (this=0x7ffff6ccabd0, socket=0x2218aa0, event=GSOCK_OUTPUT)
    at ./src/gtk/gsockgtk.cpp:119
#4  0x00007ffff63c37ef in GSocket::Disable (this=0x2218aa0, event=GSOCK_OUTPUT) at ./src/unix/gsocket.cpp:1527
#5  0x00007ffff63c42f8 in GSocket::Detected_Write (this=0x2218aa0) at ./src/unix/gsocket.cpp:1836
#6  0x00007ffff67fca1c in _GSocket_GDK_Input (data=0x2218aa0, source=19, condition=GDK_INPUT_WRITE) at ./src/gtk/gsockgtk.cpp:41
#7  0x00007ffff478e99f in gdk_io_invoke (source=<value optimized out>, condition=<value optimized out>, data=<value optimized out>)
    at /build/buildd/gtk+2.0-2.22.0/gdk/gdkevents.c:1082
#8  0x00007ffff29d0342 in g_main_dispatch (context=0xc67f10) at /build/buildd/glib2.0-2.26.1/glib/gmain.c:2149
#9  g_main_context_dispatch (context=0xc67f10) at /build/buildd/glib2.0-2.26.1/glib/gmain.c:2702
#10 0x00007ffff29d42a8 in g_main_context_iterate (context=0xc67f10, block=<value optimized out>, dispatch=<value optimized out>,
    self=<value optimized out>) at /build/buildd/glib2.0-2.26.1/glib/gmain.c:2780
#11 0x00007ffff29d47b5 in g_main_loop_run (loop=0x7fffe43371a0) at /build/buildd/glib2.0-2.26.1/glib/gmain.c:2988
#12 0x00007ffff4b4d3e7 in IA__gtk_main () at /build/buildd/gtk+2.0-2.22.0/gtk/gtkmain.c:1237
#13 0x00007ffff67faa5f in wxEventLoop::Run (this=0x7fffe4396a40) at ./src/gtk/evtloop.cpp:76
#14 0x00007ffff6896cc8 in wxAppBase::MainLoop (this=0xc67970) at ./src/common/appcmn.cpp:312
#15 0x00007ffff6896e42 in wxAppBase::OnRun (this=0xc67970) at ./src/common/appcmn.cpp:367
#16 0x00007ffff606ae5b in wxEntry (argc=@0x7ffff638f4b0, argv=0xc56e10) at ./src/common/init.cpp:448
#17 0x00007ffff606af31 in wxEntry (argc=@0x7fffffffe09c, argv=0x7fffffffe188) at ./src/common/init.cpp:460
#18 0x00000000005d0b02 in main (argc=1, argv=0x1) at amule-gui.cpp:93
Logged

btkaos

  • Global Moderator
  • Sr. Member
  • *****
  • Karma: 110
  • Offline Offline
  • Posts: 486
  • Kaos is infinite!
Re: upredictable memory leak
« Reply #68 on: January 17, 2011, 06:41:02 PM »
Well the patch didn't help, an OOM again, caused by zillions of wxSocketEvent queued.

Anyways glib's behaviour is really weird here, what could corrupt glib's context. The code involved seems to be thread safe (was my number 1 suspicion). Anyways glib/gtk was once infamous as single-threaded toolkits, and indeed gtk used to have very embarrassing limitations regarding threading.

Maybe the context shouldn't be manipulated from different threads, but it doesn't seem so. Who could overwrite the context?

It is only accessed one time, and it is surrounded by:
Code: [Select]
G_LOCK_DEFINE_STATIC (main_loop);
static GMainContext *default_main_context;
static GSList *main_contexts_without_pipe = NULL;

Regards,
BTK
Logged

btkaos

  • Global Moderator
  • Sr. Member
  • *****
  • Karma: 110
  • Offline Offline
  • Posts: 486
  • Kaos is infinite!
Re: upredictable memory leak
« Reply #69 on: January 17, 2011, 06:49:10 PM »
Just for reference:

Code: [Select]
:~/tmp/amule$ objdump -x /usr/lib/debug/lib/libglib-2.0.so.0.2600.1  | grep 2e0b
00000000002e0b28 l     O .bss 0000000000000004 counter.11490
00000000002e0b44 l     O .bss 0000000000000008 child_watch_wake_up_pipe
00000000002e0b40 l     O .bss 0000000000000004 child_watch_init_state
00000000002e0b98 l     O .bss 0000000000000004 depth_private.9210
00000000002e0b9c l     O .bss 0000000000000004 thread_context_stack
00000000002e0b60 l     O .bss 0000000000000030 g__main_context_list_lock
00000000002e0b90 l     O .bss 0000000000000008 main_context_list
00000000002e0bd0 l     O .bss 0000000000000008 main_contexts_without_pipe
00000000002e0ba0 l     O .bss 0000000000000030 g__main_loop_lock
00000000002e0bd8 l     O .bss 0000000000000008 default_main_context
00000000002e0bf0 l     O .bss 0000000000000008 profile_data
00000000002e0bf8 l     O .bss 0000000000000008 profile_allocs
00000000002e0be8 l     O .bss 0000000000000008 gmem_profile_mutex
00000000002e0be0 g     O .bss 0000000000000004 g_mem_gc_friendly

Logged

Stu Redman

  • Administrator
  • Hero Member
  • *****
  • Karma: 214
  • Offline Offline
  • Posts: 3739
  • Engines screaming
Re: upredictable memory leak
« Reply #70 on: January 17, 2011, 07:12:15 PM »
Quote from: btkaos on January 17, 2011, 04:28:33 PM
I don't yet understand fully how the download limiting works.
You don't read everything from the socket in case of an event, only as much as needed to fill your bandwidth. Then, in the next cycle, you read again (you don't need another event for this).

Quote
Well the patch didn't help, an OOM again, caused by zillions of wxSocketEvent queued.
I was afraid of that. If the events aren't processed anymore, OnReceive isn't called and event generation isn't turned off.
What wx should do:
- two flags in socket for "read event posted", "write evenet posted"
- flag is set true when event is posted
- flag is set false on Read/Write
- when flag is true no Read/Write event is posted.
Guess you can hack it in. That might cure it.
Logged
The image of mother goddess, lying dormant in the eyes of the dead, the sheaf of the corn is broken, end the harvest, throw the dead on the pyre -- Iron Maiden, Isle of Avalon

btkaos

  • Global Moderator
  • Sr. Member
  • *****
  • Karma: 110
  • Offline Offline
  • Posts: 486
  • Kaos is infinite!
Re: upredictable memory leak
« Reply #71 on: January 17, 2011, 10:28:25 PM »
Quote from: Stu Redman on January 17, 2011, 07:12:15 PM
Quote from: btkaos on January 17, 2011, 04:28:33 PM
I don't yet understand fully how the download limiting works.
You don't read everything from the socket in case of an event, only as much as needed to fill your bandwidth. Then, in the next cycle, you read again (you don't need another event for this).
Note that indeed wx *will* generate another event in that case.
From http://docs.wxwidgets.org/stable/wx_wxsocketbase.html:
Quote
The wxSOCKET_INPUT event will be issued whenever there is data available for reading. This will be the case if the input queue was empty and new data arrives, or if the application has read some data yet there is still more data available. This means that the application does not need to read all available data in response to a wxSOCKET_INPUT event, as more events will be produced as necessary.
What my patch tried to do is to disable those events, as you said aMule knows that it has data available. Picture this, aMule reads from the socket but more data is available, wx generates another event, then aMule receives the event but reads no data as it exhausted the limit, another event is generated (maybe), etc...

Of course we also have the wx
Quote
Quote
Well the patch didn't help, an OOM again, caused by zillions of wxSocketEvent queued.
I was afraid of that. If the events aren't processed anymore, OnReceive isn't called and event generation isn't turned off.
What wx should do:
- two flags in socket for "read event posted", "write evenet posted"
- flag is set true when event is posted
- flag is set false on Read/Write
- when flag is true no Read/Write event is posted.
Guess you can hack it in. That might cure it.
Yes basically we must tell glib not to generate more events until the wx event is processed. This is missing now. That is easy and no flag is needed, when receiving the glib event tell glib to mask that event, and in the wx event handler reenable it unconditionally. The event handler must assume than it is always called with the underlying socket masked for that operation. Similar to asyncronous interrupt processing, the interruption manager that particular interruption and the IH enables it again.

I was going to write a patch, but note that the wxSockets is completely different from 2.8 to 2.9, so I don't want to target 2.9 yet given that it seems very unstable.

Maybe I'll write one for wxSockets 2.8, just for checking that it solves the problem. I wouldn't rule out a bug in glib, the crash points to that.
Logged

Kry

  • Ex-developer
  • Retired admin
  • Hero Member
  • *****
  • Karma: -665
  • Offline Offline
  • Posts: 5795
Re: Re: upredictable memory leak
« Reply #72 on: January 18, 2011, 07:18:50 AM »
I don't have a working linux installed, I found out today. So, tomorrow I'll reinstall one and test all this.

You crash sounds like one I found a long time ago in wxWidgets that I didn't get to backport to them because I lost a harddrive. If that's it, I'll surely be able to fix it again.

As for the events... we'll see.
Logged

btkaos

  • Global Moderator
  • Sr. Member
  • *****
  • Karma: 110
  • Offline Offline
  • Posts: 486
  • Kaos is infinite!
Re: upredictable memory leak
« Reply #73 on: January 18, 2011, 09:06:01 PM »
Quote from: btkaos on January 17, 2011, 05:43:12 PM
With your patch again a corrupted context, damm glib this should never happen. Anyways I did see some interesting things, but I have to double check them.

Code: [Select]
(gdb) bt
#0  __pthread_mutex_lock (mutex=0x7) at pthread_mutex_lock.c:50
#1  0x00007ffff29d004f in g_source_destroy_internal (source=0x7fffdc2fe130, context=0xffffffffffffffff, have_lock=0)
    at /build/buildd/glib2.0-2.26.1/glib/gmain.c:942
#2  0x00007ffff29d290e in g_source_remove (tag=<value optimized out>) at /build/buildd/glib2.0-2.26.1/glib/gmain.c:1717
#3  0x00007ffff67fcc7d in GSocketGUIFunctionsTableConcrete::Uninstall_Callback (this=0x7ffff6ccabd0, socket=0x2218aa0, event=GSOCK_OUTPUT)
    at ./src/gtk/gsockgtk.cpp:119
#4  0x00007ffff63c37ef in GSocket::Disable (this=0x2218aa0, event=GSOCK_OUTPUT) at ./src/unix/gsocket.cpp:1527
#5  0x00007ffff63c42f8 in GSocket::Detected_Write (this=0x2218aa0) at ./src/unix/gsocket.cpp:1836
#6  0x00007ffff67fca1c in _GSocket_GDK_Input (data=0x2218aa0, source=19, condition=GDK_INPUT_WRITE) at ./src/gtk/gsockgtk.cpp:41
#7  0x00007ffff478e99f in gdk_io_invoke (source=<value optimized out>, condition=<value optimized out>, data=<value optimized out>)
    at /build/buildd/gtk+2.0-2.22.0/gdk/gdkevents.c:1082
#8  0x00007ffff29d0342 in g_main_dispatch (context=0xc67f10) at /build/buildd/glib2.0-2.26.1/glib/gmain.c:2149
#9  g_main_context_dispatch (context=0xc67f10) at /build/buildd/glib2.0-2.26.1/glib/gmain.c:2702
#10 0x00007ffff29d42a8 in g_main_context_iterate (context=0xc67f10, block=<value optimized out>, dispatch=<value optimized out>,
    self=<value optimized out>) at /build/buildd/glib2.0-2.26.1/glib/gmain.c:2780
#11 0x00007ffff29d47b5 in g_main_loop_run (loop=0x7fffe43371a0) at /build/buildd/glib2.0-2.26.1/glib/gmain.c:2988
#12 0x00007ffff4b4d3e7 in IA__gtk_main () at /build/buildd/gtk+2.0-2.22.0/gtk/gtkmain.c:1237
#13 0x00007ffff67faa5f in wxEventLoop::Run (this=0x7fffe4396a40) at ./src/gtk/evtloop.cpp:76
#14 0x00007ffff6896cc8 in wxAppBase::MainLoop (this=0xc67970) at ./src/common/appcmn.cpp:312
#15 0x00007ffff6896e42 in wxAppBase::OnRun (this=0xc67970) at ./src/common/appcmn.cpp:367
#16 0x00007ffff606ae5b in wxEntry (argc=@0x7ffff638f4b0, argv=0xc56e10) at ./src/common/init.cpp:448
#17 0x00007ffff606af31 in wxEntry (argc=@0x7fffffffe09c, argv=0x7fffffffe188) at ./src/common/init.cpp:460
#18 0x00000000005d0b02 in main (argc=1, argv=0x1) at amule-gui.cpp:93
Well the backtrace is strange but is is almost clear what is going on.

In gsocket.cpp:1836 is a usual callback for detected data operation.
Code: [Select]
    CALL_CALLBACK(this, GSOCK_OUTPUT);
CALL_CALLBACK then calls to Disable which in turn just calls to g_source_remove. Why g_source_remove fails with a valid socket is indeed a cause of mistery. Some kind of overflow?
Logged

Stu Redman

  • Administrator
  • Hero Member
  • *****
  • Karma: 214
  • Offline Offline
  • Posts: 3739
  • Engines screaming
Re: upredictable memory leak
« Reply #74 on: January 18, 2011, 10:03:42 PM »
Quote from: btkaos on January 17, 2011, 10:28:25 PM
Picture this, aMule reads from the socket but more data is available, wx generates another event, then aMule receives the event but reads no data as it exhausted the limit, another event is generated (maybe), etc...
Since we read nothing in this case, no other event should be generated.
Did you notice how all of your sockets simultaneously started piling up events? Looks like something seriously breaks in the underlying system.

What I keep thinking is, maybe we should kick out all of the wx socket usage (along with the underlying GTK networking) and use some other socket lib. Maybe Boost.Asio. It would also solve (some of) the problems with 2.9 . I seriously doubt wx devs test against aMule or anything else driving a socket lib to its limits. They probably send a few packets from A to B and think it works.
(expecting some serious flaming for this...  :-\ )
Logged
The image of mother goddess, lying dormant in the eyes of the dead, the sheaf of the corn is broken, end the harvest, throw the dead on the pyre -- Iron Maiden, Isle of Avalon
Pages: 1 ... 3 4 [5] 6 7 8
« previous next »