 |
|
You are not logged in! F.A.Q Log in Register |
 |
|
 |
 Now online (1)steve mcqueen ...and 95 guests Last 5 registered Oplandisks nothingstar N_loop yipe foxtrotromeo Browse members... |
 |
Members 8025Messages 2608865 Today 5 Topics 127230 |
|
|||||||||
| |||||||||
|
|
my code is leaking. their code is leaking. everyone's code is leaking -- leaking edge. it is. mmhmm. on my end of the stick, client notices app has spiraled into tens of gigs of memory and helpfully suggest the coder check for leaks. the coder's system is a six-core sack-of-it running linux with dust bunnies and eight gigs of ram and the client is running osx machines with four or eight times as many rams and more cores and clean fans. is it a slow leak? is it an osx leak? more importantly, is it a not-on-linux leak? if so, checking an osx leak on not-an-osx must be checked for feasability. the client is beta testing the code a lot, and indications are that it is a slow leak, which is a mixed blessing. the upside is this: the coder did not screw up terribly bad. the downside is this: it's complicated to figure out where a slow leak is coming from, because, by the time someone spots it, the whole works is dripping in mangled bits of RAM and shut 'er down clancy! leak ! how to know if slow? how to find? well, gushers are obvious. let's just pull out the leak-finder and see if it gushes and phase zero: struggle to get the built-in leak-finder that's integrated into the coding GUI. it simply says: "unknown error". thanks phase one: run the trusty command-line leak-finder, valgrind, from the command line. no gushers are apparent. relief. phase two: cumbersumblebomble around in the app. not much leaking. the app runs at a crawl from the leak-finder crawling through the RAM tubes and it is almost intolerable to do anything this is so slow aaaugh phase three: decide to just leave app open for a while and see if something starts to drip after a half-hour or so phase four: ums |
||||||||
|
|
|||||||||
| |||||||||
|
|
phase five: client emails back that, no, it's not a slow leak in the code -- it's a gusher, in the encoder part of the code. when the code is told to encode, memory gushes all over the carpet. all. over. the. carpet there is still value in leaking the app open with the still-running leakfinder to catch any slow leaks in the main code, however, and i should let it drift on for the amount of time i originally scheduled. this is tantament to a few more minutes. just in time for an update to the thread code. and a zigguraut out back code da porch |
||||||||
|
|
|||||||||
| |||||||||
|
|
http://nitrotracker.tobw.net/ you should add gameboy support to nitrotracker with your leet coding skillz do it lol |
||||||||
|
|
|||||||||
| |||||||||
|
|
phase six: there does not seem to be a gusher-on-linux in the encode part of the code. perhaps, though, it's because the RAM needs to be pressurized... like, with much larger unecoded video files. or, is the progress bar code spinning out of control and impeding the progress of the encode code? hell if inode |
||||||||
|
|
|||||||||
| |||||||||
|
|
http://nitrotracker.tobw.net/ you should add gameboy support to nitrotracker with your leet coding skillz do it lol sure! i'll need six months and five million dollars. |
||||||||
|
|
|||||||||
|
Messageboard index
|
|||||||||
