Too many warnings for world and kernel for 13 stable
Hi! There was a lot warning during build wold and kernel in past with clang 13, but with clang 14 to many warnings. Probably commiters will find some time to fix it? I spent some time to fix/supress warnings for world, exept contrib and stand parts. This patch is not to merge, it is to show that something goes wrong. >From 616ca2b8b63b225be0305d34f36dd3d0050a6a4f Mon Sep 17 00:00:00 2001 From: Rozhuk Ivan Date: Fri, 10 Sep 2021 18:50:20 +0300 Subject: [PATCH] Fix build warnings --- lib/geom/eli/geom_eli.c | 4 +- lib/libc/stdlib/rand.c| 4 +- lib/libfetch/http.c | 7 +--- lib/libkvm/kvm_minidump_powerpc64_hpt.c | 3 -- lib/libmd/rmd160c.c | 1 + lib/libmd/sha1c.c | 2 + lib/libpfctl/libpfctl.c | 16 +++ lib/libpjdlog/pjdlog.c| 5 ++- lib/libprocstat/libprocstat.c | 1 + lib/libvgl/mouse.c| 5 +-- lib/libvmmapi/vmmapi.c| 3 +- lib/ncurses/ncurses/termcap.c | 2 - sbin/bsdlabel/bsdlabel.c | 8 +--- sbin/camcontrol/zone.c| 7 +--- sbin/ggate/ggated/ggated.c| 42 +++ sbin/growfs/growfs.c | 5 +-- sbin/ipfw/ipfw2.c | 5 +-- sbin/ipfw/nat.c | 3 +- sbin/ipfw/nat64clat.c | 3 +- sbin/ipfw/nat64lsn.c | 3 +- sbin/ipfw/nat64stl.c | 3 +- sbin/ipfw/nptv6.c | 3 +- sbin/ipfw/tables.c| 6 +-- sbin/nvmecontrol/modules/wdc/wdc.c| 3 +- sbin/pfctl/pfctl_optimize.c | 3 -- sbin/recoverdisk/recoverdisk.c| 14 +-- sys/amd64/vmm/vmm_instruction_emul.c | 18 ++-- sys/netinet/libalias/alias.c | 11 +++-- usr.bin/backlight/backlight.c | 3 -- usr.bin/ipcs/ipc.c| 3 +- usr.bin/mkuzip/mkuzip.c | 8 ++-- usr.bin/mt/mt.c | 5 +-- usr.bin/procstat/procstat.c | 3 +- usr.bin/truss/syscalls.c | 7 +--- usr.bin/unifdef/unifdef.c | 5 +-- usr.bin/units/units.c | 5 --- usr.bin/vmstat/vmstat.c | 4 +- usr.bin/vtfontcvt/vtfontcvt.c | 8 usr.sbin/acpi/acpidump/acpi.c | 5 --- usr.sbin/bhyve/atkbdc.c | 12 ++ usr.sbin/bhyve/bhyverun.c | 12 ++ usr.sbin/bhyve/gdb.c | 14 ++- usr.sbin/bhyve/hda_codec.c| 22 +++--- usr.sbin/bhyve/mem.c | 26 usr.sbin/bhyve/mevent.c | 4 +- usr.sbin/bhyve/pci_ahci.c | 20 - usr.sbin/bhyve/pci_e82545.c | 8 +--- usr.sbin/bhyve/pci_emul.c | 26 usr.sbin/bhyve/pci_hda.c | 31 -- usr.sbin/bhyve/pci_virtio_block.c | 10 ++--- usr.sbin/bhyve/pci_virtio_console.c | 8 +--- usr.sbin/bhyve/pci_virtio_net.c | 7 +--- usr.sbin/bhyve/pci_virtio_rnd.c | 5 +-- usr.sbin/bhyve/pci_virtio_scsi.c | 4 +- usr.sbin/bhyve/pm.c | 10 + usr.sbin/bhyve/rtc.c | 21 -- usr.sbin/bhyve/spinup_ap.c| 22 -- usr.sbin/bhyve/task_switch.c | 22 +++--- usr.sbin/bhyve/uart_emul.c| 13 ++ usr.sbin/bhyve/vga.c | 8 ++-- usr.sbin/bsdinstall/partedit/scripted.c | 7 ++-- usr.sbin/camdd/camdd.c| 19 + usr.sbin/efibootmgr/efibootmgr.c | 3 +- usr.sbin/efidp/efidp.c| 3 +- .../fifolog/fifolog_reader/fifolog_reader.c | 4 +- usr.sbin/fifolog/lib/fifolog_int.c| 2 +- usr.sbin/fifolog/lib/fifolog_reader.c | 4 +- usr.sbin/fifolog/lib/fifolog_write_poll.c | 2 +- usr.sbin/fifolog/lib/getdate.y| 13 +- usr.sbin/fwcontrol/fwdv.c | 4 +- usr.sbin/makefs/msdos.c | 2 - usr.sbin/makefs/msdos/msdosfs_vfsops.c| 2 - usr.sbin/mpsutil/mps_debug.c | 2 - usr.sbin/mptable/mptable.c| 3 -- usr.sbin/pmc/cmd_pmc_filter.cc| 3 +- usr.sbin/pw/pw_user.c | 4 +- usr.sbin/rpc.lockd/kern.c | 5 --- usr.sbin/rpc.tlsservd/rpc.tlsservd.c | 3 +- usr.sbin/rrenumd/parser.y
Re: CURRENT: llvm13 seem to miscompile dns/bind916 (9.16.23)
> On 25 Nov 2021, at 18:50, FreeBSD User wrote: > > Running CURRENT (FreeBSD 14.0-CURRENT #7 main-n250911-a11983366ea7: Mon Nov > 22 18:17:54 > CET 2021 amd64) troubles me with our DNS server/service. > Aproximately the same time we switched on CURRENT to the CURRENT LLVM13 > version and also, > after the compilation of a fresh OS with LLVM13, the upgrade from > bind-9.16.22 to > bind-9.16.23 took place as well as ASLR being the default. > > Since then named is crashing with a mysterious segmentation fault (see PR > 259921, > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259921). > > Disabling ASLR as recommended to check whether ASLR triggers the SegFault did > not solve > the problem, so I suspect a miscompilation due to llvm13. > > On 13-STABLE bind-9.16.23 seem not to have this behaviour. > > I'm floating like a dead man in the water, can someone help? lang/sdcc also seg faults (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260303), although there disabling ASLR via proccontrol does fix it. Can you show a stacktrace for your seg fault? -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum
Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main
> On 17 Nov 2021, at 09:00, Marcin Wojtas wrote: > As of b014e0f15bc7 the ASLR (Address Space Layout > Randomization) feature becomes enabled for the all 64-bit > binaries by default. Firstly, thank your for your efforts here, it is appreciated :) I am finding that the lang/sdcc port is crashing with a seg fault and the core dump is no help to me at all: [freebsd14 7:06] /usr/ports/lang/sdcc/work/sdcc-4.0.0/device/lib >sudo gdb ../../bin/sdcc sdcc.core GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD] Reading symbols from ../../bin/sdcc... [New LWP 100122] Core was generated by `../../bin/sdcc -I../../device/include -I../../device/include/mcs51 -mds390 --nos'. Program terminated with signal SIGSEGV, Segmentation fault. Invalid permissions for mapped object. #0 0x000804e3fbc0 in setrlimit () from /lib/libc.so.7 (gdb) info thread Id Target Id Frame * 1LWP 1001220x000804e3fbc0 in setrlimit () from /lib/libc.so.7 (gdb) bt #0 0x000804e3fbc0 in setrlimit () from /lib/libc.so.7 Backtrace stopped: Cannot access memory at address 0x7f87fd08 If I disable ASLR (via proccontrol) then it does not crash, but I am not sure how I can debug it further. I've raised a bug https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260303 if you (or anyone else) has suggestions for what to try. Thanks. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum
Re: 14-current: unable to boot after upgrade (installworld)
On 2021-12-09 05:36, Sergey V. Dyatko wrote: Hi, Yesterday I tried to upgrade old 13-current (svn rev r368473) to fresh 14-current from git,it looked like this: 1) git pull https://git.freebsd.org/src.git /usr/src 2) cd /usr/src ; make buildworld; make kernel Not sure you didn't actually do this. But it appears that you omitted a: make install kernel here. 3) shutdown -r now after that I _successfully_ booted into 14-current and continued with etcupdate -p make installworld etcupdate -B shutdown -r now but after that server doesn't come back. After I conneted to this server via IPMI ip-kvm I saw following (sorry for external link): https://i.imgur.com/jH6MHd2.png Well. There was a migration to zol between r368473 and current 'main' branch so I decided to install fresh 14-current from snapshot FreeBSD-14.0-CURRENT-amd64-20211202-610d908f8a6-251253 in order to avoid possible problems and again, after make kernel and reboot OS runs, but after installworld I ended up in the same situation thoughts ? -- wbr, Sergey
Re: 14-current: unable to boot after upgrade (installworld)
> On 10. Dec 2021, at 16:57, Chris wrote: > > On 2021-12-09 05:36, Sergey V. Dyatko wrote: >> Hi, >> Yesterday I tried to upgrade old 13-current (svn rev r368473) to fresh >> 14-current from git,it looked like this: >> 1) git pull https://git.freebsd.org/src.git /usr/src >> 2) cd /usr/src ; make buildworld; make kernel > Not sure you didn't actually do this. But it appears that you omitted a: > make install kernel > here. `make kernel` does buildkernel and installkernel. -m >> 3) shutdown -r now >> after that I _successfully_ booted into 14-current and continued with >> etcupdate -p >> make installworld >> etcupdate -B >> shutdown -r now >> but after that server doesn't come back. After I conneted to this server via >> IPMI ip-kvm I saw following (sorry for external link): >> https://i.imgur.com/jH6MHd2.png >> Well. There was a migration to zol between r368473 and current 'main' branch >> so >> I decided to install fresh 14-current from snapshot >> FreeBSD-14.0-CURRENT-amd64-20211202-610d908f8a6-251253 in order to avoid >> possible problems >> and again, after make kernel and reboot OS runs, but after installworld I >> ended up >> in the same situation >> thoughts ? >> -- >> wbr, Sergey
Panic: Page Fault in Kernel: Yesterday's CURRENT
FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #15
main-n251537-ab639f2398b: Thu Dec 9 19:45:37 CST 2021
r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL amd64
VMCORE *IS* available.
Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 20
fault virtual address = 0x0
fault code = supervisor write data, page not present
instruction pointer = 0x20:0x804e0db4
stack pointer = 0x0:0xfe0434de4e10
frame pointer = 0x0:0xfe0434de4e70
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= resume, IOPL = 0
current process = 82990 (c++)
trap number = 12
panic: page fault
cpuid = 0
time = 163998
KDB: stack backtrace:
#0 0x8050fc95 at kdb_backtrace+0x65
#1 0x804c468f at vpanic+0x17f
#2 0x804c4503 at panic+0x43
#3 0x807a2195 at trap_fatal+0x385
#4 0x807a21ef at trap_pfault+0x4f
#5 0x80779c78 at calltrap+0x8
#6 0x8045ddb8 at handleevents+0x188
#7 0x8045ea3e at timercb+0x24e
#8 0x807ca9eb at lapic_handle_timer+0x9b
#9 0x8077b9b1 at Xtimerint+0xb1
Uptime: 2h28m57s
Dumping 12829 out of 131023
MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n"
(offsetof(struct pcpu,
(kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1 doadump (textdump=)
at /usr/src/sys/kern/kern_shutdown.c:399
#2 0x804c428c in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:487
#3 0x804c46fe in vpanic (fmt=0x807e1276 "%s",
ap=) at /usr/src/sys/kern/kern_shutdown.c:920
#4 0x804c4503 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:844
#5 0x807a2195 in trap_fatal (frame=0xfe0434de4d50, eva=0)
at /usr/src/sys/amd64/amd64/trap.c:946
#6 0x807a21ef in trap_pfault (frame=0xfe0434de4d50,
usermode=false, signo=, ucode=)
at /usr/src/sys/amd64/amd64/trap.c:765
#7
#8 0x804e0db4 in callout_process (now=now@entry=38385536922300)
at /usr/src/sys/kern/kern_timeout.c:488
#9 0x8045ddb8 in handleevents (now=now@entry=38385536922300,
fake=fake@entry=0) at /usr/src/sys/kern/kern_clocksource.c:213
#10 0x8045ea3e in timercb (et=0x80d475e0 ,
arg=) at /usr/src/sys/kern/kern_clocksource.c:357
#11 0x807ca9eb in lapic_handle_timer (frame=0xfe0434de4f40)
at /usr/src/sys/x86/x86/local_apic.c:1364
#12
#13 0x00080df42bb6 in ?? ()
Backtrace stopped: Cannot access memory at address 0x7def2c90
(kgdb)
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: 14-current: unable to boot after upgrade (installworld)
> On 9. Dec 2021, at 20:54, Sergey Dyatko wrote:
>
> tiger@dl:~ % gpart show
>
> |
> =>40 3907029088 da4 GPT (1.8T)
> 4010241 freebsd-boot (512K)
>1064 984 - free - (492K)
>2048 39070269442 freebsd-zfs (1.8T)
> 3907028992 136 - free - (68K)
>
> =>40 3907029088 da5 GPT (1.8T)
> 4010241 freebsd-boot (512K)
>1064 984 - free - (492K)
>2048 39070269442 freebsd-zfs (1.8T)
> 3907028992 136 - free - (68K)
>
> =>40 3907029088 da6 GPT (1.8T)
> 4010241 freebsd-boot (512K)
>1064 984 - free - (492K)
>2048 39070269442 freebsd-zfs (1.8T)
> 3907028992 136 - free - (68K)
>
> =>40 3907029088 da7 GPT (1.8T)
> 4010241 freebsd-boot (512K)
>1064 984 - free - (492K)
>2048 39070269442 freebsd-zfs (1.8T)
> 3907028992 136 - free - (68K)
>
> i'm not sure about video, everything happens faster than I can see :-) but
> sometimes the system does not freeze and I can enter commands. Can this
> help in some way?
>
maybe, maybe not; from one hand, BTX register dump may help us to identify
possible location or give other clues - eip=004cfrom your screenshot is
telling us that some structure with function pointers must have been corrupted,
seems like NULL pointer derefernce caused by this corruption. So the
investigation should try to identify what is causing such corruption….
Since it was booting before, does the old loader start? I see the iKVM windo
does have record menu entry, can it be used to record whole incident?
rgds,
toomas
> чт, 9 дек. 2021 г. в 18:19, Toomas Soome :
>
>>
>>
>>> On 9. Dec 2021, at 20:06, Sergey Dyatko wrote:
>>>
>>> I was sure the installer did it when I reinstalled the system from
>> scratch. I
>>> can load 14-current successfully after boot via PXE and installworld with
>>> 13-current
>>> now I did the following:
>>> 1) boot from HDDs FreeBSD 14.0-CURRENT #0 main-n251494-f953785b3df (with
>>> 'old' world)
>>> 2)run installworld (f953785b3df)
>>> 3) run `gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da${D}`
>>> command , where D=4..7
>>> root@dl:/usr/src # zpool status
>>> pool: zroot
>>> state: ONLINE
>>> config:
>>>
>>> NAMESTATE READ WRITE CKSUM
>>> zroot ONLINE 0 0 0
>>> mirror-0 ONLINE 0 0 0
>>> da4p2 ONLINE 0 0 0
>>> da5p2 ONLINE 0 0 0
>>> mirror-1 ONLINE 0 0 0
>>> da6p2 ONLINE 0 0 0
>>> da7p2 ONLINE 0 0 0
>>> errors: No known data errors
>>>
>>> after `shutdown -r now` system still doesn't boot with the same error.
>> As
>>> far I can see, there is /boot/lua/config.lua present, but when I try to
>> run
>>> command more /boot/lua/config.lua system hangs with following error:
>>> https://imgur.com/5p0xu6W.png
>>>
>>
>> You seem to get 2x BTX panic, could you try to create video from console,
>> so we could get register dumps?
>>
>> can this system do UEFI boot and if so, can you test it? Could you post
>> partition tables?
>>
>> rgds,
>> toomas
>>
>>
>>>
>>> чт, 9 дек. 2021 г. в 15:56, Warner Losh :
>>>
On Thu, Dec 9, 2021 at 7:58 AM Tomoaki AOKI
wrote:
> On Thu, 9 Dec 2021 13:36:10 +
> "Sergey V. Dyatko" wrote:
>
>> Hi,
>>
>> Yesterday I tried to upgrade old 13-current (svn rev r368473) to fresh
>> 14-current from git,it looked like this:
>> 1) git pull https://git.freebsd.org/src.git /usr/src
>> 2) cd /usr/src ; make buildworld; make kernel
>> 3) shutdown -r now
>> after that I _successfully_ booted into 14-current and continued with
>> etcupdate -p
>> make installworld
>> etcupdate -B
>> shutdown -r now
>>
>> but after that server doesn't come back. After I conneted to this
server
> via
>> IPMI ip-kvm I saw following (sorry for external link):
>> https://i.imgur.com/jH6MHd2.png
>>
>> Well. There was a migration to zol between r368473 and current 'main'
> branch so
>> I decided to install fresh 14-current from snapshot
>> FreeBSD-14.0-CURRENT-amd64-20211202-610d908f8a6-251253 in order to
avoid
>> possible problems
>>
>> and again, after make kernel and reboot OS runs, but after
>> installworld
> I ended up in the same situation
>>
>> thoughts ?
>>
>> --
>> wbr, Sergey
>>
>>
>
> Bootcode should be updated.
> The procedure you wrote doesn't seem to update it.
>
The posted error is one you get when you can't read the filesystem,
>> which
is why you need to update
Re: Panic: Page Fault in Kernel: Yesterday's CURRENT
Hi Larry,
This looks like some use-after-free or otherwise corrupted callout
structure. Unfortunately the backtrace does not tell what was the
callout. When was the previous update to look what could change?
On 10.12.2021 11:24, Larry Rosenman wrote:
> FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #15
> main-n251537-ab639f2398b: Thu Dec 9 19:45:37 CST 2021
> r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL amd64
>
> VMCORE *IS* available.
>
>
>
>
> Unread portion of the kernel message buffer:
> kernel trap 12 with interrupts disabled
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 20
> fault virtual address = 0x0
> fault code = supervisor write data, page not present
> instruction pointer = 0x20:0x804e0db4
> stack pointer = 0x0:0xfe0434de4e10
> frame pointer = 0x0:0xfe0434de4e70
> code segment = base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags = resume, IOPL = 0
> current process = 82990 (c++)
> trap number = 12
> panic: page fault
> cpuid = 0
> time = 163998
> KDB: stack backtrace:
> #0 0x8050fc95 at kdb_backtrace+0x65
> #1 0x804c468f at vpanic+0x17f
> #2 0x804c4503 at panic+0x43
> #3 0x807a2195 at trap_fatal+0x385
> #4 0x807a21ef at trap_pfault+0x4f
> #5 0x80779c78 at calltrap+0x8
> #6 0x8045ddb8 at handleevents+0x188
> #7 0x8045ea3e at timercb+0x24e
> #8 0x807ca9eb at lapic_handle_timer+0x9b
> #9 0x8077b9b1 at Xtimerint+0xb1
> Uptime: 2h28m57s
> Dumping 12829 out of 131023
> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
>
> __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
> 55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n"
> (offsetof(struct pcpu,
> (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
> #1 doadump (textdump=)
> at /usr/src/sys/kern/kern_shutdown.c:399
> #2 0x804c428c in kern_reboot (howto=260)
> at /usr/src/sys/kern/kern_shutdown.c:487
> #3 0x804c46fe in vpanic (fmt=0x807e1276 "%s",
> ap=) at /usr/src/sys/kern/kern_shutdown.c:920
> #4 0x804c4503 in panic (fmt=)
> at /usr/src/sys/kern/kern_shutdown.c:844
> #5 0x807a2195 in trap_fatal (frame=0xfe0434de4d50, eva=0)
> at /usr/src/sys/amd64/amd64/trap.c:946
> #6 0x807a21ef in trap_pfault (frame=0xfe0434de4d50,
> usermode=false, signo=, ucode=)
> at /usr/src/sys/amd64/amd64/trap.c:765
> #7
> #8 0x804e0db4 in callout_process (now=now@entry=38385536922300)
> at /usr/src/sys/kern/kern_timeout.c:488
> #9 0x8045ddb8 in handleevents (now=now@entry=38385536922300,
> fake=fake@entry=0) at /usr/src/sys/kern/kern_clocksource.c:213
> #10 0x8045ea3e in timercb (et=0x80d475e0 ,
> arg=) at /usr/src/sys/kern/kern_clocksource.c:357
> #11 0x807ca9eb in lapic_handle_timer (frame=0xfe0434de4f40)
> at /usr/src/sys/x86/x86/local_apic.c:1364
> #12
> #13 0x00080df42bb6 in ?? ()
> Backtrace stopped: Cannot access memory at address 0x7def2c90
> (kgdb)
>
>
>
--
Alexander Motin
Re: Panic: Page Fault in Kernel: Yesterday's CURRENT
14-2021_12_07-1217 - - 1.87G 2021-12-07 12:17
14-2021_12_09-1957 NR / 121G 2021-12-09 19:57
If that's any help
On 12/10/2021 10:36 am, Alexander Motin wrote:
Hi Larry,
This looks like some use-after-free or otherwise corrupted callout
structure. Unfortunately the backtrace does not tell what was the
callout. When was the previous update to look what could change?
On 10.12.2021 11:24, Larry Rosenman wrote:
FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #15
main-n251537-ab639f2398b: Thu Dec 9 19:45:37 CST 2021
r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL
amd64
VMCORE *IS* available.
Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 20
fault virtual address = 0x0
fault code = supervisor write data, page not present
instruction pointer = 0x20:0x804e0db4
stack pointer = 0x0:0xfe0434de4e10
frame pointer = 0x0:0xfe0434de4e70
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = resume, IOPL = 0
current process = 82990 (c++)
trap number = 12
panic: page fault
cpuid = 0
time = 163998
KDB: stack backtrace:
#0 0x8050fc95 at kdb_backtrace+0x65
#1 0x804c468f at vpanic+0x17f
#2 0x804c4503 at panic+0x43
#3 0x807a2195 at trap_fatal+0x385
#4 0x807a21ef at trap_pfault+0x4f
#5 0x80779c78 at calltrap+0x8
#6 0x8045ddb8 at handleevents+0x188
#7 0x8045ea3e at timercb+0x24e
#8 0x807ca9eb at lapic_handle_timer+0x9b
#9 0x8077b9b1 at Xtimerint+0xb1
Uptime: 2h28m57s
Dumping 12829 out of 131023
MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n"
(offsetof(struct pcpu,
(kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1 doadump (textdump=)
at /usr/src/sys/kern/kern_shutdown.c:399
#2 0x804c428c in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:487
#3 0x804c46fe in vpanic (fmt=0x807e1276 "%s",
ap=) at /usr/src/sys/kern/kern_shutdown.c:920
#4 0x804c4503 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:844
#5 0x807a2195 in trap_fatal (frame=0xfe0434de4d50, eva=0)
at /usr/src/sys/amd64/amd64/trap.c:946
#6 0x807a21ef in trap_pfault (frame=0xfe0434de4d50,
usermode=false, signo=, ucode=)
at /usr/src/sys/amd64/amd64/trap.c:765
#7
#8 0x804e0db4 in callout_process
(now=now@entry=38385536922300)
at /usr/src/sys/kern/kern_timeout.c:488
#9 0x8045ddb8 in handleevents (now=now@entry=38385536922300,
fake=fake@entry=0) at /usr/src/sys/kern/kern_clocksource.c:213
#10 0x8045ea3e in timercb (et=0x80d475e0 ,
arg=) at /usr/src/sys/kern/kern_clocksource.c:357
#11 0x807ca9eb in lapic_handle_timer
(frame=0xfe0434de4f40)
at /usr/src/sys/x86/x86/local_apic.c:1364
#12
#13 0x00080df42bb6 in ?? ()
Backtrace stopped: Cannot access memory at address 0x7def2c90
(kgdb)
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Re: 14-current: unable to boot after upgrade (installworld)
On 2021-12-10 08:01, Michael Gmelin wrote: On 10. Dec 2021, at 16:57, Chris wrote: On 2021-12-09 05:36, Sergey V. Dyatko wrote: Hi, Yesterday I tried to upgrade old 13-current (svn rev r368473) to fresh 14-current from git,it looked like this: 1) git pull https://git.freebsd.org/src.git /usr/src 2) cd /usr/src ; make buildworld; make kernel Not sure you didn't actually do this. But it appears that you omitted a: make install kernel here. `make kernel` does buildkernel and installkernel. Right you are. I read it as make BUILDkernel. Sorry. :-/ -m 3) shutdown -r now after that I _successfully_ booted into 14-current and continued with etcupdate -p make installworld etcupdate -B shutdown -r now but after that server doesn't come back. After I conneted to this server via IPMI ip-kvm I saw following (sorry for external link): https://i.imgur.com/jH6MHd2.png Well. There was a migration to zol between r368473 and current 'main' branch so I decided to install fresh 14-current from snapshot FreeBSD-14.0-CURRENT-amd64-20211202-610d908f8a6-251253 in order to avoid possible problems and again, after make kernel and reboot OS runs, but after installworld I ended up in the same situation thoughts ? -- wbr, Sergey 0xBDE49540.asc Description: application/pgp-keys
Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main
Hi Daniel pt., 10 gru 2021 o 10:16 Daniel O'Connor napisał(a): > > > > > On 17 Nov 2021, at 09:00, Marcin Wojtas wrote: > > As of b014e0f15bc7 the ASLR (Address Space Layout > > Randomization) feature becomes enabled for the all 64-bit > > binaries by default. > > Firstly, thank your for your efforts here, it is appreciated :) > > I am finding that the lang/sdcc port is crashing with a seg fault and the > core dump is no help to me at all: > [freebsd14 7:06] /usr/ports/lang/sdcc/work/sdcc-4.0.0/device/lib >sudo gdb > ../../bin/sdcc sdcc.core > GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD] > > Reading symbols from ../../bin/sdcc... > [New LWP 100122] > Core was generated by `../../bin/sdcc -I../../device/include > -I../../device/include/mcs51 -mds390 --nos'. > Program terminated with signal SIGSEGV, Segmentation fault. > Invalid permissions for mapped object. > #0 0x000804e3fbc0 in setrlimit () from /lib/libc.so.7 > (gdb) info thread > Id Target Id Frame > * 1LWP 1001220x000804e3fbc0 in setrlimit () from > /lib/libc.so.7 > (gdb) bt > #0 0x000804e3fbc0 in setrlimit () from /lib/libc.so.7 > Backtrace stopped: Cannot access memory at address 0x7f87fd08 > > If I disable ASLR (via proccontrol) then it does not crash, but I am not sure > how I can debug it further. > > I've raised a bug https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260303 if > you (or anyone else) has suggestions for what to try. > Thanks for filing the ticket. Let's continue the conversation there. Best regards, Marcin
Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main
On Fri, Dec 10, 2021 at 06:35:47PM +0100, Marcin Wojtas wrote: > Hi Daniel > > > pt., 10 gru 2021 o 10:16 Daniel O'Connor napisał(a): > > > > > > > > > On 17 Nov 2021, at 09:00, Marcin Wojtas wrote: > > > As of b014e0f15bc7 the ASLR (Address Space Layout > > > Randomization) feature becomes enabled for the all 64-bit > > > binaries by default. > > > > Firstly, thank your for your efforts here, it is appreciated :) > > > > I am finding that the lang/sdcc port is crashing with a seg fault and the > > core dump is no help to me at all: > > [freebsd14 7:06] /usr/ports/lang/sdcc/work/sdcc-4.0.0/device/lib >sudo gdb > > ../../bin/sdcc sdcc.core > > GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD] > > > > Reading symbols from ../../bin/sdcc... > > [New LWP 100122] > > Core was generated by `../../bin/sdcc -I../../device/include > > -I../../device/include/mcs51 -mds390 --nos'. > > Program terminated with signal SIGSEGV, Segmentation fault. > > Invalid permissions for mapped object. > > #0 0x000804e3fbc0 in setrlimit () from /lib/libc.so.7 > > (gdb) info thread > > Id Target Id Frame > > * 1LWP 1001220x000804e3fbc0 in setrlimit () from > > /lib/libc.so.7 > > (gdb) bt > > #0 0x000804e3fbc0 in setrlimit () from /lib/libc.so.7 > > Backtrace stopped: Cannot access memory at address 0x7f87fd08 > > > > If I disable ASLR (via proccontrol) then it does not crash, but I am not > > sure how I can debug it further. > > > > I've raised a bug https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260303 > > if you (or anyone else) has suggestions for what to try. > > > > Thanks for filing the ticket. Let's continue the conversation there. I left a comment there. The gist of it is that there are several lingering problems with the stack gap implementation, and I think we should re-disable it on main until there's some consensus on how to proceed.
