标签: debugging

我用来od打印文件/标准输入/字符串的八进制或十六进制。这让我可以看到标准输入的 ASCII 或 UTF-8 编码值。

但我们不再生活在 ASCII 世界了。是否有任何命令可以打印出（假设）utf-8 编码输入的 unicode 值/代码点？我想知道我看到的是什么 unicode 字符？

我相信我们遇到了 GTX 1080（驱动程序）和 PCI Passthrough 的可能错误。

我的主机是 Ubuntu 14.04 系统。我的来宾是 Ubuntu 14.04/16.04 系统（两者都做同样的事情）。

我可以在来宾 VM 中看到设备：

$ lspci -vnn | grep VGA
00:05.0 VGA compatible controller: NVIDIA Corporation Device 1b80 (rev a1)

我能够成功安装驱动程序（370.2，最新驱动程序）。它安装，但不被识别nvidia-smi：

$ nvidia-smi 
Unable to determine the device handle for GPU 0000:00:05.0: Unknown Error

查看dmesg我看到以下错误消息

[29.535583] nvidia 0000:00:05.0: irq 45 for MSI/MSI-X
[29.577727] NVRM: RmInitAdapter failed! (0x23:0x56:458)
[29.577807] NVRM: rm_init_adapter failed for device bearing minor number 0

我可以将 GTX 1080 换成不同的卡（M4000，在来宾上执行直通和安装驱动程序）并且它可以工作。明天我将尝试使用另一张 Geforce 卡。

NVidia …

很明显，GDB 可以生成进程的核心转储，例如通过它的包装器 - gcore，但是不清楚它究竟包含什么，而且很难找到答案，因为不同的来源说完全不同的东西。

因此，我有以下问题：

1. 它是否包含进程的整个虚拟内存？如果不是，那是哪一部分？所有可写区域或仅堆栈或仅（顾名思义）某些重要部分或什么？

2. 是否可以通过 GDB 生成具有完整进程内存的核心文件？如果是这样，如何？

3. 通过根据进程的内存映射保存和连接所有区域的内存生成的“转储”与使用gcore命令自动生成的文件有什么区别？

4. 一个进程将一些数据写入 RAM 的某处。我可以确定数据将（始终）访问并保存在使用gcore命令生成的核心文件中吗？如果不是，为什么？它取决于什么？

我有一系列失败/有时失败的 SD 卡。它们要么提供以下dmesg输出之一：

完全死掉的（不要在 处列出/dev/mmcblk0）：

[  +0,000010] mmc0: error -110 whilst initializing SD card 
[  +2,819983] mmc0: card never left busy state

失败的（偶尔仍然可以安装）：

[Jun16 06:28] mmc0: new high speed SDHC card at address 0001
[  +0,000339] mmcblk0: mmc0:0001 00000 3.68 GiB 
[  +0,002835]  mmcblk0: p1 p2 p3 p4
[ +10,256689] mmcblk0: timed out sending r/w cmd command, card status 0x900
[ +11,264358] mmcblk0: timed out sending r/w cmd command, card status 0x900
[  +0,000016] print_req_error: I/O …

我的电脑需要很长时间才能启动。我有理由相信这是由 grub 之后的延迟引起的，但在内核日志记录开始之前（启动需要 30 秒，但dmesg消息在0.00000-之间有时间戳9.34223，这篇文章中有详细信息）。

有什么方法可以调试正在发生的事情吗？特别是：

• 有没有办法让 grub 本身更详细，或者保留日志？
• grub 和内核日志记录之间是否还有其他可能需要时间的进程？我如何调试这些？

我相信这个问题不是特定于我的设置。但以防万一，我正在运行 Ubuntu 16.10 和 grub(2)

编辑：

按照@TooTea 的建议，我设置了debug=all环境变量，这些变量产生了很多script/script.c:50 malloc 0x7a9a2ca0应该不成问题的消息。然后有一个消息块与 8 秒延迟延迟一致：

kern/dl.c:56 Detecting ext2... 
lib/relocator.c:1397 chunks = 0x7a7e0ae0
lib/relocator.c:434 trying to allocate in ...-... aligned ... size ...
lib/relocator.c:1198 allocated: ...+...
lib/relocator.c:1409 allocated .../...
lib/relocator.c:1410  chunks = 0x7a7e0ae0

在 zsh 中，是否可以将set -x( set -o xtrace)的跟踪输出定向到 stderr 以外的文件描述符？

我正在寻找一种等效的方法$BASH_XTRACEFD或一种模拟相同行为的方法。

问题

在我的笔记本电脑上安装 Fedora 30 (KDE) 后，我的路由器在我连接到它后不久就会崩溃。当我通过有线以太网和 Wi-Fi 连接时，都会发生这种情况。幸运的是，路由器日志提供了有关为什么会发生这种情况的线索。我会收到这样的警告：

kern.err kernel: [ 116.293427] ipq806x-gmac-dwmac 37200000.ethernet eth0: len 1675 larger than size (1536)

其次是：

daemon.warn dnsmasq[2721]: reducing DNS packet size for nameserver 92.220.228.70 to 1280

对于第一条消息，我在 OpenWrt 论坛上发现了一个帖子，其他人也遇到了同样的问题。事实证明，交换机驱动程序中的一个错误会导致内核在收到大于默认 MTU (1500) 的数据包时发生恐慌，也就是“巨型帧”。

该线程中的其他人没有收到第二个警告，但我认为这与我的情况有关。

当我使用 Fedora 29 时，我从未遇到过这种情况，网络上的所有其他设备都可以正常连接。因此，Fedora 30 中肯定引入了一些错误。

我所观察到的

我已经尝试了几件事，看看我是否可以连接到路由器而不会导致警告和崩溃。我将在下面列出它们。

Wi-Fi，启用网络管理器

能够连接，但导致警告和崩溃。ifconfig输出 MTU 为 1500。

Wi-Fi，启用 NetworkManager 并且在 KDE 系统设置中将 MTU 设置为 1500

能够连接，但导致警告和崩溃。ifconfig输出 MTU 为 1500。

Wi-Fi，禁用网络管理器并手动连接

$ sudo wpa_supplicant -B -iwlp18s0 -cwpa.conf …

我想调试我没有源代码的已加载内核模块；我怀疑是病毒。有没有办法将其输入 GDB 进行分析？

我有一个 Busybox/Linux 系统，其中一个神秘程序很少出现段错误。有没有办法找到哪个程序在做这个？

首先，简要描述一下情况：一台计算机隐藏在某种画廊的显示器附近，充当一件作品的无声主力。尽管程序员的本意是最好的，但根据路人与显示器的互动，该作品可能会时不时地崩溃。由于正常运行时间（或类似的东西）非常宝贵，程序员已经安装了计算机以使用 bash 循环黑客式地自动重新启动相关程序。

开发人员很想确定任何崩溃的原因是什么，但是通过 GDB 运行程序——据开发人员所知——会导致进程在崩溃时停止。这确实使开发人员能够利用“回溯”并找到原因，但是在开发人员前往相关画廊进行检查之前，该作品将无法操作。这不好。

这个勇敢的开发人员如何通过 GDB 保护每次崩溃的回溯（并可能将它们存储在某个地方），但仍然允许在崩溃时自动重新启动进程的原始行为？