gunnar12
commented
6 years ago Been 10yrs since I built a linux debug, gdb system.
Any chance of some help, a makefile making a debug version?
Or some hints on how to change the makefile? (havnt made them in 20 yrs and always a pain)
Reason, to attack that long-short average but first find out why new nethogs crashing with segmen falt for me.
gdb, withyout debug symbols, points to
received signal SIGSEGV, Segmentation fault. 0x000000000040b2ee in getcmdlineabi:cxx11 ()
getcmdline starts with
std::string getcmdline(pid_t pid) { const int maxfilenamelen = 14 + MAX_PID_LENGTH + 1; char filename[maxfilenamelen];
std::snprintf(filename, maxfilenamelen, "/proc/%d/cmdline", pid);
so I just added length to see if it helps (orig might crash in 2 or 22 hours? never made it to 24 hours for me)
const int maxfilenamelen = 14 + MAX_PID_LENGTH + 1024;
I guess the cmdline is added to that string by the code that follows? (lost there too wthout reading the actl assembly, I have also stayed away from basic self-allocated and -freed strings on magic stacks, except when really needed)
Note, the (ffmpeg, for me) cmdline can be very-very long, much-much longer than a PID
Gunnar
PS I was going toshorten the cmdline anyway, string-search for the important information to match the width of nethog terminal window. Additionally skip some PIDs, like traffic for local samba-networking. Plus keep the sorting order more or less constant, avoid the bursty downloads jumping up and down in list.
PPS not walked thrgh the interface to pcap yet, used it 10 yrs ago on windos but never got to them "filters". I just captured some video-protocols, rtmp at that time. Any hint on what is done where??
Is the idea to have pcap just do a callback(after initing it) with the total number of bits, at certain time intervals? But there seems to be lots of validation, detection of socket traffic protocols, headers??
PPPS Nethogs also seems to "keep socket-zombies"?? Any code for checking if alrdy found "live sockets" still exist??
(my actual problem is actually bad old ffmpeg getting randomly (socket?) stuck deep down in some socket-library (for HLS video traffic). Been like that for years, somebody forgot abt timeouts and watchdogs when hooking up the HLS.c code to the get-URL-data stuff) WHo knows what then happens in that ffmpeg HLS-socket (the debugger knows??)
Note, the old rtmp-code seems to have some timeouts implemented?
Thanks for -l command line option, was "pretty useless" before that. (my hookup 8-12 ffmpeg, was impsble too know whoiswho by just PID, now simple and beautiful)
But, another standard thing often missing is SHORT and LONG term speed average.
Most video-downld now in bursts of appr 2-10MB fragments,segments,chunks a 10s video Even using a 32sec average doesnt really help as the segments too often come in bursts (from the segment list.
Perfect soluttion wld be SHORT and LONG TIME averages. Somthng typ like 2s and 60s. Maybe a 10minute too?
I tend to use simple (but somehwat demanding) recursive filters, not "running averages", actual "addition of last 1024 1s speed samples". Needs dbl precision, or floating point
out = (in-out)/N + out ; average over N samples, like 64,128..etc like rightshiffts.
same as a "servo style" out = error/N + out, where error=in-out.
Noting that division is a rightshift easy to understand one needs "dblprecision" with integers. in-out goes "to upper" and then shifted log(N) positions down.
Gunnar
PS You can do a 2de order "average filter" too, PPS My (now) old patent, now used in all audio,DSP etc hw and sw processing, hehe..