Backtrace stopped: previous frame identical to this frame (corrupt stack?) , even with fresh qemu and linux build

[Mulyadi Santosa]

On Fri, Apr 22, 2022 at 7:30 PM Chan Kim <ckim at etri.re.kr> wrote:

> Hello all,
>
> Really strange thing happening here.. I can't see the full stack trace with
> 'bt' command in gdb.
> So I tried with fresh linux-5.10.122 source and qemu-6.2.0 source and it's
> happening too!
> (it's happening when I do combinations with linux 5.10.0 and qemu-5.1.0.
> But
> it's not happening with linux-5.4.21)
>
> I would be grateful if somebody could check if this happens to other people
> or just me.
>
> 1. download linux-5.1.122 tarball from https://www.kernel.org/
> 2. uncompress it and set env variable ARCH=arm64,
> CROSS_COMPILE=aarch64-none-elf- , do "make defconfig" and "make -j`nproc`
> Image"
> 3. download qemu-6.2.0 from https://www.qemu.org/
> 4. uncompress it and do "mkdir build" "cd build" "../configure
> --target-list=aarch64-softmmu --enable-debug"
> 5. run qemu and wait for debugger to attach.
> qemu-6.2.0/build/aarch64-softmmu/qemu-system-aarch64 -machine
> virt,gic-version=max,secure=off,virtualization=true -cpu max -kernel
> linux-5.10.112/arch/arm64/boot/Image -m 2G -nographic -netdev
> user,id=vnet,hostfwd=:127.0.0.1:0-:22,tftp=/srv/tftp -device
> virtio-net-pci,netdev=vnet -machine iommu=smmuv3 --append "root=/dev/ram
> init=/init nokaslr earlycon ip=dhcp hugepages=16" -s -S
> 6. run debugger, do "aarch64-none-elf-gdb linux-6.10.112/vmlinux -x\
>

It has been long time since I compiled linux kernel but I guess, either you
need to compile kernel with enabled frame pointer, and/or you need to
enable debug symbol embedded into final kernel image. cmiiw


> gdb_script"
> (gdb_script content :
> target remote :1234
> layout src
> b start_kernel
> b __driver_attach
> )
>
> Now, in gdb, when you press 'c' twice, it'll stop at the first
> __driver_attach. (first one stops at start_kernel).
> When you are at __attach_driver, type 'bt'. See if you see the full
> function
> stack trace.
> This is what I see.
> (gdb) bt
> #0  __driver_attach (dev=0xffff000002582810, data=0xffff800011dc2358
> <dummy_regulator_driver+40>)
>     at drivers/base/dd.c:1060
> #1  0xffff8000107a3ed0 in bus_for_each_dev (bus=<optimized out>,
> start=<optimized out>,
>     data=0xffff800011dc2358 <dummy_regulator_driver+40>,
> fn=0xffff8000107a6f60 <__driver_attach>)
>     at drivers/base/bus.c:305
> #2  0xd6d78000107a5c58 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>
> I used to see more thatn 20 stacks trace but strangely I see only two.
> I can still see many stacks for linux-5.4.21 that I was working with in the
> past.
> Could anyone check if this happens to anyone?
> I think if I add BLK_DEV_RAM and set initramfs.cpio.gz in the linux build,
> the kernel will boot ok to the shell prompt.
> Only the gdb can't show the stack levels.
>
> My OS : ubuntu-20.04  5.13.0-35-generic
>
> $ aarch64-none-elf-gdb --version
> GNU gdb (GNU Toolchain for the A-profile Architecture 10.2-2020.11
> (arm-10.16)) 10.1.90.20201028-git
> Copyright (C) 2020 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> Thank you.
> Chan Kim
>
>
>
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>


-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20220422/734ead10/attachment.html>