Not if you get some refugee one in the US
where did you get the child blood?
it was on discount
I've noticed on one of my laptops that xfce4-terminal seems to have a memory leak. Over time, and regardless of whether the terminal is idle or not, the memory usage gradually increases infinitely. Any idea how this could be debugged?
additionally, if the terminals are launched with --disable-server, the total memory leaked is the same as if all the terminals shared the same process, however then memory is not freed until all terminals have exited
trfl: it is possible. do you observe it also with gnome-terminal?
I'll install it and leave it open, but it'll take 4-6 hours until we know :>
on second thought, alpine doesn't have gnome-terminal... :p
installed urxvt and mate-terminal, I'll leave those open for a while!
looks like it only affects xfce4-terminal, judging by all the other terminals sitting at 0% cpu load however xfce4-terminal is idling at 17%
cpu usage may not mean anythin
we have an alpine clang+compiler-rt+libc++ bootstrap
now rebuild the entire distro and lets see how broken it is ;)
to be honest, the most problematic packages were... the LLVM ones
a few outliers aside, everything went smoothly once i figured out how to bootstrap/fix those
(said outliers being like... go :P)
I am booting alpine in a using qemu/kvm. rc-service start networking throws me * Starting networking ...awk: out of memory * ERROR: networking failed to start . What should it be the cause ?
kvm option is -m 2048 which is sufficient memory I guess
regarding my xfce4-terminal memory leak, looks like that's the only affected terminal. There's heavy communication between the terminal process and another process called gmain on file descriptor 3 (a unix socket), about 200 KB/s of binary data, in case that might help track it down
Shiz, excuse my ignorance, what are you trying to achieve and what are the benefits regarding your work with llvm?
Going to the beach now so will read your reply later.
clandmeter: not depending on gcc.
basically the same benefits as those listed under "using musl" in ncopa's FOSDEM presentation
(correcting code, improving portability, etc)
clandmeter: eventually we want to compile all packages with Control Flow Integrity support (which is kind of like the grsecurity RAP stuff except for userspace)
clandmeter: CFI is in clang, not in gcc, so we need to evaluate using clang as system compiler to achieve that goal