01:19:49 hello, i have freebsd 14 guest in QEMU, vim does not work correctly under console. 01:22:10 i thought it was TERM, the default was vt100, i tried xterm, xterm-256color, same issue. 01:25:44 freebsd 14 defaults to kern.hz=100 in QEMU, which is cool. last time i tried (freebsd 13?) it got high cpu usage. 01:31:22 i wonder how do i fix this: Feb 6 03:27:04 green kernel: cannot forward src fe80:19::4e6d:580f:fc89:81ae, dst 2001:7d0:8437:136d:280:a3ff:fe91:3f77, nxt 58, rcvif vlan3, outif vlan9 01:32:06 vlan3 is wan, vlan9 has ripe atlas probe, vlan3 actually doesn't have any ipv6 except ll 01:32:14 :/ 01:32:36 about same time, some icmp comes in 01:32:47 ttl reached iirc 01:33:32 update: the vim issue disappeared after a reboot 01:36:05 library cache was busted? 01:37:57 ketas: to me? i don't know, the vim issue appears at first time installation. 01:38:17 yes 01:38:42 because how come vim is fixed after reboot 01:38:46 under a normal installation, then pkg update ; pkg install vim, and the issue appears 01:41:17 what issue was it 01:42:42 simply not working correctly, e.g. when open vim, press ESC, it prints "[" on the left ">" on the right, press "i", try to input something, ramdom stuff was input 01:52:58 uuidNuniq: wtf 01:57:50 oh boy, the `pkg` command is more powerful than any of pacman apt yum dnf 05:57:12 lw: thanks for pointing that out, new to me 06:19:31 on FreeBSD 14 ThinkPad T400 can I check that battery charge threshold control works rather than has errors? I used a script called battery_ctrl.sh but I'm unsure I didn't get errors... I'm installing XFCE but so far in that on any FreeBSD PC the system tray's power manager always crashed (that would show the percentage and if it's charging or dissipating down to a threshold) 08:43:33 darwin: ACPI should expose the most basic information, but for anything else there's sysutils/hwstat in ports/packages. 08:44:10 ACPI information is exposed via OIDs using sysctl(8). 08:55:07 I want to use the malloc debugger electric fence while developing a program. My program runs fine on OpenBSD, NetBSD and linux but on FreeBSD the program crashes even before the main() function is reached, in the debugger I see references to /lib/libthr.so.3 and the eletric fence initialization routines. I'm completely stomped. Does anyone have any idea what's going on? 08:59:42 Ok, I've narrowed it down. I created a test program which only calls malloc() and free() and then exists. This works great with electric fence but when I also link to libpcap, I get the same problem. Why would linking to -lpcap and -lefence cause the program to crash during exec initialization? 09:08:00 This is the debugger output from a program doing nothing other than malloc() and free() linked with -lpcap -lefence: https://pastebin.com/fQLkyBsb 09:08:01 Title: thalos@freebsd132:~/test $ lldb -- test(lldb) target create "test"Current ex - Pastebin.com 09:16:24 libthr is threads; i think you need an extra link with your program 09:19:09 I tried adding -lthr and -lpthread and both, still didn't work 09:19:44 this seems like a question for the electric fence people 09:21:09 Right.. 09:24:07 you also might want a debug version of libthr so you have some useful symbols 09:24:28 would help diagnose the problem 09:25:09 I'm not super into FreeBSD, how do you install debug versions of system libraries on freebsd? 09:28:04 you can build them or from https://download.freebsd.org/releases/amd64/amd64/14.0-RELEASE/ *-dbg.txz 09:28:05 Title: Index of /releases/amd64/amd64/14.0-RELEASE/ 09:28:38 if you're horsing around with electric fence on linux and openbsd, why do you also need it on freebsd? 09:28:46 i mean, it looks for leaks, right? 09:33:07 You're right, technically I only need it on one platform. I'm just overly cautious and want to keep the makefile clean from exceptions. But I think I might just not use efence on freebsd. I've spent enough time on it. This does look like a bug somewhere though so it might benefit everyone to getting it fixed 09:34:00 your stack trace show's something in efence crashing, so i'd report it with them. 09:34:38 but no one is going to care with ___lldb_unnamed_symbol549 so you better get some unstripped libraries 09:40:55 Wait a minute, correct me if I'm wrong but couldn't the stack trace I provided indicate that there are some problem in libthr? 09:44:14 i suppose it's possible, you won't know until you know the full stack 09:44:26 electric fence is not hooking on malloc like valgrind would do, it's just providing symbols for malloc() ect at link time 09:47:59 babz: So what are you saying? 09:50:00 build a static executable 09:56:40 mmh valgrind 10:00:30 Here's the test program linked statically. Seems like libthr is tripping up calling _thr_alloc().. https://pastebin.com/3XACrW0d 10:00:31 Title: thalos@freebsd132:~/test $ lldb ./test(lldb) target create "./test"Current e - Pastebin.com 10:01:13 paulf: I might just switch to valgrind if nothing else because it's more comprehensive 10:06:16 good idea ;-) 14:58:16 libpcap has some static data which libthr calls calloc to allocate memory for, efence calls printf but libthr is not fully initialized yet so it crashes. I don't think the malloc interposition interface for FreeBSD is specified anywhere, but the most sensible solution would be to do what musl does which is call internal malloc when the system libraries are not ready for arbitrary user code 15:03:02 you can work around this particular issue by exporting EF_DISABLE_BANNER=1 15:03:48 it's also pretty dubious that calling write(2) requires dynamic allocation, the main thread storage should be statically allocated 15:05:00 oh, the TLS block isn't initialized, not dynamically allocated 19:18:37 is "bectl jail" supposed to mount devfs? it's not very useful without it as there's no devices, even /dev/null 19:50:53 lw: nope 19:56:45 scronk 20:20:39 lw: add "-o 'mount.devfs=true' " 20:28:15 All of my jails have /dev with at least /dev/null in them. I rarely need the full devfs mounted. 21:17:50 Oh, it's not an explicit jail but a boot environment. Gotcha. 21:27:11 rwp: that's the default behavior for mounting devfs in a jail 21:27:18 rules applied will typically hide almost everything by default 21:27:57 and bectl(8) used to just use libjail and spawn its own jail that way, but then people complained that they wanted to use more options from jail(8) and we had to push it to exec'ing jail(8) instead 21:44:05 feels like there should be a way to make -o mount.devfs=true the default 21:46:35 Hello71: Thanks for the clarification. I tried exporting EF_DISABLE_BANNER=1 in my test program but it doesn't seem to solve the problem. A quick search turned up that electric fence 2.2.2-21 has a bug where this flag is not honored, dunno if this applies to FreeBSD, I haven't checked the src but seems like the freebsd package is using electric fence 2.2.2_2 (pkg info) so maybe? 22:00:03 lw: *shrug* I didn't really intend for bectl-jail to be the right thing for everyone out of the box, more of a building block much like jail(8) itself is 23:50:37 Thanks for the background kevens on bectl-jail. I like knowing how things got to where they are now. 23:50:53 s/kevens/kevans/ ^^ 23:51:01 even so 23:52:30 I am aware that mounting layers another mount point on top and shadows the underlying files of the under-mount point. I rather count on that. I almost always populate /dev with the bare minimum of device nodes and symlinks such as /dev/null and depending upon what *other* people have written stdout,stdin,stderr,random and such too. And then I usually don't need to mount the full devfs in a jail. 23:54:02 But there are jails that we set up as jails. And then there are jails that bectl-jail might set up which there I think of differently. I have never needed to use bectl-jail but am happy to have the feature available in the case that I did need it. And I am one of those people that very often uses jail(8) directly with everything on the command line to build a temporary jail for a short term use. 23:55:37 in this case i just wanted to run some pkg commands + edit loader.conf, i used pkg -r in the end but jail would be an easier way to do that 23:57:03 Among jails and chroots and commands supporting working in in specific directories there are many ways to do the same thing.