hello, i have freebsd 14 guest in QEMU, vim does not work correctly under console.

i thought it was TERM, the default was vt100, i tried xterm, xterm-256color, same issue.

freebsd 14 defaults to kern.hz=100 in QEMU, which is cool. last time i tried (freebsd 13?) it got high cpu usage.

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

vlan3 is wan, vlan9 has ripe atlas probe, vlan3 actually doesn't have any ipv6 except ll

:/

about same time, some icmp comes in

ttl reached iirc

update: the vim issue disappeared after a reboot

library cache was busted?

ketas: to me? i don't know, the vim issue appears at first time installation.

yes

because how come vim is fixed after reboot

under a normal installation, then pkg update ; pkg install vim, and the issue appears

what issue was it

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

uuidNuniq: wtf

oh boy, the `pkg` command is more powerful than any of pacman apt yum dnf

lw: thanks for pointing that out, new to me

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)

darwin: ACPI should expose the most basic information, but for anything else there's sysutils/hwstat in ports/packages.

ACPI information is exposed via OIDs using sysctl(8).

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?

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?

This is the debugger output from a program doing nothing other than malloc() and free() linked with -lpcap -lefence: pastebin.com/fQLkyBsb

Title: thalos@freebsd132:~/test $ lldb -- test(lldb) target create "test"Current ex - Pastebin.com

libthr is threads; i think you need an extra link with your program

I tried adding -lthr and -lpthread and both, still didn't work

this seems like a question for the electric fence people

Right..

you also might want a debug version of libthr so you have some useful symbols

would help diagnose the problem

I'm not super into FreeBSD, how do you install debug versions of system libraries on freebsd?

you can build them or from download.freebsd.org/releases/amd64/amd64/14.0-RELEASE *-dbg.txz

Title: Index of /releases/amd64/amd64/14.0-RELEASE/

if you're horsing around with electric fence on linux and openbsd, why do you also need it on freebsd?

i mean, it looks for leaks, right?

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

your stack trace show's something in efence crashing, so i'd report it with them.

but no one is going to care with ___lldb_unnamed_symbol549 so you better get some unstripped libraries

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?

i suppose it's possible, you won't know until you know the full stack

electric fence is not hooking on malloc like valgrind would do, it's just providing symbols for malloc() ect at link time

babz: So what are you saying?

build a static executable

mmh valgrind

Here's the test program linked statically. Seems like libthr is tripping up calling _thr_alloc().. pastebin.com/3XACrW0d

Title: thalos@freebsd132:~/test $ lldb ./test(lldb) target create "./test"Current e - Pastebin.com

paulf: I might just switch to valgrind if nothing else because it's more comprehensive

good idea ;-)

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

you can work around this particular issue by exporting EF_DISABLE_BANNER=1

it's also pretty dubious that calling write(2) requires dynamic allocation, the main thread storage should be statically allocated

oh, the TLS block isn't initialized, not dynamically allocated

is "bectl jail" supposed to mount devfs? it's not very useful without it as there's no devices, even /dev/null

lw: nope

scronk

lw: add "-o 'mount.devfs=true' "

All of my jails have /dev with at least /dev/null in them. I rarely need the full devfs mounted.

Oh, it's not an explicit jail but a boot environment. Gotcha.

rwp: that's the default behavior for mounting devfs in a jail

rules applied will typically hide almost everything by default

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

feels like there should be a way to make -o mount.devfs=true the default

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?

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

Thanks for the background kevens on bectl-jail. I like knowing how things got to where they are now.

s/kevens/kevans/ ^^

even so

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.

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.

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

Among jails and chroots and commands supporting working in in specific directories there are many ways to do the same thing.