On Fri, 27 Jun 2025 21:55:25 +0200 Harald Welte <[email protected]> wrote:>
Package: dynamips
Version: 0.2.14-1+b1
Severity: important
dynamips on unstable fails to run a cisco software image which I've been using
with dynamips
for 12 years:
---
dynamips@nataraja:~$ dynamips c7200-itpk9-mz.124-15.SW.bin
Cisco Router Simulation Platform (version 0.2.14-amd64/Linux stable)
Copyright (c) 2005-2011 Christophe Fillot.
Build date: Apr 26 2024 21:50:16
Local UUID: 6d084a0e-f1de-4570-b465-357ee0e9ba9a
IOS image file: c7200-itpk9-mz.124-15.SW.bin
ILT: loaded table "mips64j" from cache.
ILT: loaded table "mips64e" from cache.
ILT: loaded table "ppc32j" from cache.
ILT: loaded table "ppc32e" from cache.
CPU0: carved JIT exec zone of 64 Mb into 2048 pages of 32 Kb.
C7200 instance 'default' (id 0):
VM Status : 0
RAM size : 256 Mb
IOMEM size : 0 Mb
NVRAM size : 128 Kb
NPE model : npe-400
Midplane : vxr
IOS image : c7200-itpk9-mz.124-15.SW.bin
Loading ELF file 'c7200-itpk9-mz.124-15.SW.bin'...
ELF entry point: 0x80008000
C7200 'default': starting simulation (CPU0 PC=0xffffffffbfc00000), JIT enabled.
ROMMON emulation microcode.
Launching IOS image at 0x80008000...
Self decompressing the image :
###################################################################################################################################
[OK]
Segmentation fault (core dumped)
---
Journalctl says:
---
Jun 27 21:53:40 nataraja systemd-coredump[2459218]: [🡕] Process 2459200
(dynamips) of user 2009 dumped core.
Module libsystemd.so.0 from
deb systemd-257.7-1.amd64
Module libzstd.so.1 from
deb libzstd-1.5.7+dfsg-1.amd64
Module libuuid.so.1 from
deb util-linux-2.41-5.amd64
Stack trace of thread
2459214:
#0 0x00007ffbe837bd98
__printf_buffer_init_end (libc.so.6 + 0x87d98)
#1 0x00007ffbe8410aa0
___snprintf_chk (libc.so.6 + 0x11caa0)
#2 0x000055ab0916f07c
cpu_log (/usr/bin/dynamips + 0x3407c)
#3 0x000055ab091a7b12
dev_c7200_iofpga_access (/usr/bin/dynamips + 0x6cb12)
#4 0x000055ab09175f0d
mips64_mts32_lhu (/usr/bin/dynamips + 0x3af0d)
#5 0x00007ffbe13a6cc9 n/a
(n/a + 0x0)
ELF object binary
architecture: AMD x86-64
---
When using a debian 12 (stable) lxc container on the same machine, dynamips
works fine. So it seems like a
regression between the build for debian bookworm and unstable.
Hello Harald,
I just tried to find out why it is crashing.
And it happens with this instruction, inside glibc:
=> 0x7f365e01bd98 <__vsnprintf_internal+72>: movaps %xmm0,(%rsp)
(rr) print/x $rsp
$1 = 0x7f36501fe5f8
(rr) bt
#0 0x00007f365e01bd98 in __printf_buffer_init_end (buf=0x7f36501fe5f8, base=0x7f36501fe7c8
"", end=0x7f36501fe8c8 "\200\b\363z\217U", mode=__printf_buffer_mode_snprintf)
at ../include/printf_buffer.h:124
#1 __printf_buffer_init (buf=0x7f36501fe5f8, base=0x7f36501fe7c8 "",
len=256, mode=__printf_buffer_mode_snprintf) at ../include/printf_buffer.h:137
#2 __printf_buffer_snprintf_init (buf=0x7f36501fe5f8, buffer=0x7f36501fe7c8
"", length=256) at ./libio/vsnprintf.c:61
#3 __vsnprintf_internal (string=string@entry=0x7f36501fe7c8 "",
maxlen=maxlen@entry=256, format=0x558f51dd5d55 "CPU%u: %s",
args=args@entry=0x7f36501fe6b8, mode_flags=mode_flags@entry=2) at ./libio/vsnprintf.c:95
#4 0x00007f365e0b0aa0 in ___snprintf_chk (s=s@entry=0x7f36501fe7c8 "",
maxlen=maxlen@entry=256, flag=flag@entry=1, slen=slen@entry=256, format=format@entry=0x558f51dd5d55
"CPU%u: %s") at ./debug/snprintf_chk.c:38
#5 0x0000558f51d5907c in snprintf (__fmt=0x558f51dd5d55 "CPU%u: %s", __n=256,
__s=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/stdio2.h:54
#6 cpu_log (cpu=cpu@entry=0x558f7af9d6e0, module=module@entry=0x558f51dd77ae
"IO_FPGA", format=format@entry=0x558f51ddf480 "read from addr 0x%x, pc=0x%llx
(size=%u)\n") at ./stable/cpu.c:128
#7 0x0000558f51d91b12 in dev_c7200_iofpga_access (cpu=0x558f7af9d6e0, dev=<optimized
out>, offset=928, op_size=2, op_type=<optimized out>, data=0x7f36501fea00) at
./common/dev_c7200_iofpga.c:637
#8 0x0000558f51d5ff0d in dev_access_fast (data=0x7f36501fea00, op_type=0, op_size=2,
offset=<optimized out>, dev_id=<optimized out>, cpu=<optimized out>) at
./common/device.h:94
#9 mips64_mts32_access (data=<optimized out>, op_type=<optimized out>, op_size=<optimized
out>, op_code=<optimized out>, vaddr=<optimized out>, cpu=<optimized out>) at
./stable/mips64_mem.c:439
#10 mips64_mts32_lhu (cpu=0x558f7af9d8f0, vaddr=18446744072610907040,
reg=<optimized out>) at ./stable/mips_mts.c:183
#11 0x00007f36540e2cc9 in ?? ()
#12 0x0000558f51d62fe5 in mips64_jit_tcb_exec (block=<optimized out>,
cpu=<optimized out>) at ./stable/mips64_amd64_trans.h:58
#13 mips64_jit_tcb_run (block=<optimized out>, cpu=<optimized out>) at
./stable/mips64_jit.c:687
#14 mips64_jit_run_cpu (gen=<optimized out>) at ./stable/mips64_jit.c:775
#15 0x00007f365e026b7b in start_thread (arg=<optimized out>) at
./nptl/pthread_create.c:448
#16 0x00007f365e0a45f0 in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:100
And unfortunately $rsp is not aligned at a 16 byte boundary,
which seems to be causing the crash.
This may be a result of the JIT usage.
And leads to this upstream pull request:
https://github.com/GNS3/dynamips/pull/129
A package built with this single patch applied seems
to no longer crash.
Kind regards,
Bernhard
apt source dynamips
cd dynamips-0.2.14
wget
https://github.com/GNS3/dynamips/commit/38e0c26aa34d38b5b002814842c688c6439c7a37.patch
-O debian/patches/38e0c26aa34d38b5b002814842c688c6439c7a37.patch
echo 38e0c26aa34d38b5b002814842c688c6439c7a37.patch >> debian/patches/series
dpkg-buildpackage
