You are not logged in!

Log in

Now online (4)
...and 36 guests

Last 5 registered

Browse members...
Members 8025
Messages 2505974
Today 27
Topics 122322
Messageboard index

offline EpicMegatrax from Greatest Hits on 2017-07-12 18:26 [#02524770]
Points: 8783 Status: Regular

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.

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


offline EpicMegatrax from Greatest Hits on 2017-07-12 18:49 [#02524780]
Points: 8783 Status: Regular

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


offline umbroman3 from United Kingdom on 2017-07-12 19:00 [#02524781]
Points: 1525 Status: Regular

you should add gameboy support to nitrotracker with your
leet coding skillz

do it



offline EpicMegatrax from Greatest Hits on 2017-07-12 19:18 [#02524782]
Points: 8783 Status: Regular

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


offline EpicMegatrax from Greatest Hits on 2017-07-12 19:18 [#02524783]
Points: 8783 Status: Regular | Followup to umbroman3: #02524781

you should add gameboy support to nitrotracker with your
leet coding skillz

do it


sure! i'll need six months and five million dollars.


Messageboard index