[Touch-packages] [Bug 1950393] Re: GDM session crashes on suspend on Ubuntu 21.10
Hi Daniel, In my understanding, the crash is not reproducible after my workaround (switching to the nvidia driver), because the nvidia-resume.service is not masked (my theory). Therefore, I switched back to the Nouveau driver, and I reproduced the problem and collected the system logs as you asked. Now prevboot.txt contains the logs from a clean boot, through the session crash and ends with a (user requested) reboot. Just for the record, these are the steps to reproduce the bug: 1. Install Ubuntu 21.10 on a laptop(?) with an nvidia GPU 2. Open "Software & Updates" -> "Additional Drivers" 3. Select the latest driver (470) 4. Reboot 5. Login normally on GDM 6. Open "Software & Updates" -> "Additional Drivers" 7. Select "Nouveau display driver" and apply the changes 8. Reboot 9. Login normally on GDM 10. Try to suspend the system 11. You should observe a session crash here ** Attachment added: "System journal for the previous boot, as requested in update #8" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950393/+attachment/5540130/+files/prevboot.txt -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1950393 Title: GDM session crashes on suspend on Ubuntu 21.10 Status in gdm3 package in Ubuntu: Incomplete Status in systemd package in Ubuntu: Incomplete Bug description: Since I started using kernel 5.13.0-20 (and 5.13.0-21) on Ubuntu 21.10, my GDM session crashes when I try to put my laptop to standby. I've attached a relevant slice of the system journal that starts from the moment I pressed the power button, configured to trigger suspend, in my case. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: xorg 1:7.7+22ubuntu2 ProcVersionSignature: Ubuntu 5.13.0-21.21-generic 5.13.18 Uname: Linux 5.13.0-21-generic x86_64 ApportVersion: 2.20.11-0ubuntu71 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: unknown CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Wed Nov 10 00:47:13 2021 DistUpgraded: 2021-10-16 23:05:19,206 DEBUG Running PostInstallScript: '/usr/lib/ubuntu-advantage/upgrade_lts_contract.py' DistroCodename: impish DistroVariant: ubuntu ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation HD Graphics 530 [8086:191b] (rev 06) (prog-if 00 [VGA controller]) Subsystem: Lenovo HD Graphics 530 [17aa:380a] Subsystem: Lenovo GM107M [GeForce GTX 950M] [17aa:380b] InstallationDate: Installed on 2020-03-17 (602 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) MachineType: LENOVO 80RU ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.13.0-21-generic root=UUID=0e855d19-79da-402d-9586-b7bfe9a9622a ro SourcePackage: xorg Symptom: display Title: Xorg crash UpgradeStatus: Upgraded to impish on 2021-10-16 (24 days ago) dmi.bios.date: 08/09/2017 dmi.bios.release: 1.61 dmi.bios.vendor: LENOVO dmi.bios.version: E5CN61WW dmi.board.asset.tag: No Asset Tag dmi.board.name: Lenovo ideapad 700-15ISK dmi.board.vendor: LENOVO dmi.board.version: NO DPK dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Lenovo ideapad 700-15ISK dmi.ec.firmware.release: 1.22 dmi.modalias: dmi:bvnLENOVO:bvrE5CN61WW:bd08/09/2017:br1.61:efr1.22:svnLENOVO:pn80RU:pvrLenovoideapad700-15ISK:rvnLENOVO:rnLenovoideapad700-15ISK:rvrNODPK:cvnLENOVO:ct10:cvrLenovoideapad700-15ISK:skuLENOVO_MT_80RU_BU_idea_FM_Lenovoideapad700-15ISK: dmi.product.family: IDEAPAD dmi.product.name: 80RU dmi.product.sku: LENOVO_MT_80RU_BU_idea_FM_Lenovo ideapad 700-15ISK dmi.product.version: Lenovo ideapad 700-15ISK dmi.sys.vendor: LENOVO version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.107-8ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 21.2.2-1ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx 21.2.2-1ubuntu1 version.xserver-xorg-core: xserver-xorg-core 2:1.20.13-1ubuntu1 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2build1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200714-1ubuntu2 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-1build1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1950393/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1950393] Re: GDM session crashes on suspend on Ubuntu 21.10
Interesting update Given the "Unit nvidia-resume.service is masked" complain by systemd- logind in my previous comment, I thought it could be related with the switching on and off the proprietary nvidia driver: after turning it on, I turned it off (switching to Nouveau) because of this other bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1947614 So, I opened the "Software & Updates" tool and in "Additional Drivers" I turned nvidia-driver-470 on again and... voila', the session-crash-on-suspend bug disappeared. It looks like to me that the tool messed up some systemd units like nvidia-resume.service and it didn't return them to the previous state after I switched back to Nouveau. Note: the only thing I used to turn on and off the nvidia driver is that "Software & Updates" tool, no custom configurations/hacks at all. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1950393 Title: GDM session crashes on suspend on Ubuntu 21.10 Status in gdm3 package in Ubuntu: Incomplete Status in systemd package in Ubuntu: New Bug description: Since I started using kernel 5.13.0-20 (and 5.13.0-21) on Ubuntu 21.10, my GDM session crashes when I try to put my laptop to standby. I've attached a relevant slice of the system journal that starts from the moment I pressed the power button, configured to trigger suspend, in my case. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: xorg 1:7.7+22ubuntu2 ProcVersionSignature: Ubuntu 5.13.0-21.21-generic 5.13.18 Uname: Linux 5.13.0-21-generic x86_64 ApportVersion: 2.20.11-0ubuntu71 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: unknown CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Wed Nov 10 00:47:13 2021 DistUpgraded: 2021-10-16 23:05:19,206 DEBUG Running PostInstallScript: '/usr/lib/ubuntu-advantage/upgrade_lts_contract.py' DistroCodename: impish DistroVariant: ubuntu ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation HD Graphics 530 [8086:191b] (rev 06) (prog-if 00 [VGA controller]) Subsystem: Lenovo HD Graphics 530 [17aa:380a] Subsystem: Lenovo GM107M [GeForce GTX 950M] [17aa:380b] InstallationDate: Installed on 2020-03-17 (602 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) MachineType: LENOVO 80RU ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.13.0-21-generic root=UUID=0e855d19-79da-402d-9586-b7bfe9a9622a ro SourcePackage: xorg Symptom: display Title: Xorg crash UpgradeStatus: Upgraded to impish on 2021-10-16 (24 days ago) dmi.bios.date: 08/09/2017 dmi.bios.release: 1.61 dmi.bios.vendor: LENOVO dmi.bios.version: E5CN61WW dmi.board.asset.tag: No Asset Tag dmi.board.name: Lenovo ideapad 700-15ISK dmi.board.vendor: LENOVO dmi.board.version: NO DPK dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Lenovo ideapad 700-15ISK dmi.ec.firmware.release: 1.22 dmi.modalias: dmi:bvnLENOVO:bvrE5CN61WW:bd08/09/2017:br1.61:efr1.22:svnLENOVO:pn80RU:pvrLenovoideapad700-15ISK:rvnLENOVO:rnLenovoideapad700-15ISK:rvrNODPK:cvnLENOVO:ct10:cvrLenovoideapad700-15ISK:skuLENOVO_MT_80RU_BU_idea_FM_Lenovoideapad700-15ISK: dmi.product.family: IDEAPAD dmi.product.name: 80RU dmi.product.sku: LENOVO_MT_80RU_BU_idea_FM_Lenovo ideapad 700-15ISK dmi.product.version: Lenovo ideapad 700-15ISK dmi.sys.vendor: LENOVO version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.107-8ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 21.2.2-1ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx 21.2.2-1ubuntu1 version.xserver-xorg-core: xserver-xorg-core 2:1.20.13-1ubuntu1 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2build1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200714-1ubuntu2 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-1build1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1950393/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1950393] Re: GDM session crashes on suspend on Ubuntu 21.10
If I grep for `systemd`, after the first meaningful message: Nov 10 00:20:06 lenovo systemd-logind[11553]: Power key pressed. The first error is: Nov 10 00:20:11 lenovo systemd-logind[11553]: Error during inhibitor- delayed operation (already returned success to client): Unit nvidia- resume.service is masked. And later: Nov 10 00:20:13 lenovo /usr/libexec/gdm-x-session[12386]: (EE) systemd- logind disappeared (stopped/restarted?) ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1950393 Title: GDM session crashes on suspend on Ubuntu 21.10 Status in gdm3 package in Ubuntu: Incomplete Status in systemd package in Ubuntu: New Bug description: Since I started using kernel 5.13.0-20 (and 5.13.0-21) on Ubuntu 21.10, my GDM session crashes when I try to put my laptop to standby. I've attached a relevant slice of the system journal that starts from the moment I pressed the power button, configured to trigger suspend, in my case. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: xorg 1:7.7+22ubuntu2 ProcVersionSignature: Ubuntu 5.13.0-21.21-generic 5.13.18 Uname: Linux 5.13.0-21-generic x86_64 ApportVersion: 2.20.11-0ubuntu71 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: unknown CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Wed Nov 10 00:47:13 2021 DistUpgraded: 2021-10-16 23:05:19,206 DEBUG Running PostInstallScript: '/usr/lib/ubuntu-advantage/upgrade_lts_contract.py' DistroCodename: impish DistroVariant: ubuntu ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation HD Graphics 530 [8086:191b] (rev 06) (prog-if 00 [VGA controller]) Subsystem: Lenovo HD Graphics 530 [17aa:380a] Subsystem: Lenovo GM107M [GeForce GTX 950M] [17aa:380b] InstallationDate: Installed on 2020-03-17 (602 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) MachineType: LENOVO 80RU ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.13.0-21-generic root=UUID=0e855d19-79da-402d-9586-b7bfe9a9622a ro SourcePackage: xorg Symptom: display Title: Xorg crash UpgradeStatus: Upgraded to impish on 2021-10-16 (24 days ago) dmi.bios.date: 08/09/2017 dmi.bios.release: 1.61 dmi.bios.vendor: LENOVO dmi.bios.version: E5CN61WW dmi.board.asset.tag: No Asset Tag dmi.board.name: Lenovo ideapad 700-15ISK dmi.board.vendor: LENOVO dmi.board.version: NO DPK dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Lenovo ideapad 700-15ISK dmi.ec.firmware.release: 1.22 dmi.modalias: dmi:bvnLENOVO:bvrE5CN61WW:bd08/09/2017:br1.61:efr1.22:svnLENOVO:pn80RU:pvrLenovoideapad700-15ISK:rvnLENOVO:rnLenovoideapad700-15ISK:rvrNODPK:cvnLENOVO:ct10:cvrLenovoideapad700-15ISK:skuLENOVO_MT_80RU_BU_idea_FM_Lenovoideapad700-15ISK: dmi.product.family: IDEAPAD dmi.product.name: 80RU dmi.product.sku: LENOVO_MT_80RU_BU_idea_FM_Lenovo ideapad 700-15ISK dmi.product.version: Lenovo ideapad 700-15ISK dmi.sys.vendor: LENOVO version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.107-8ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 21.2.2-1ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx 21.2.2-1ubuntu1 version.xserver-xorg-core: xserver-xorg-core 2:1.20.13-1ubuntu1 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2build1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200714-1ubuntu2 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-1build1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1950393/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1848200] Re: gdb not stopping on breakpoint in a 32-bit program
*** This bug is a duplicate of bug 1846557 ***
https://bugs.launchpad.net/bugs/1846557
Thanks Miroslav for opening this bug, two weeks after me opening bug #1846557.
Unfortunately, it took proving that gdb couldn't debug properly _any_ 32-bit
program, not just kernels running on QEMU, in order to get some attention.
Honestly, I didn't even thought the bug could be _that_ bad and I didn't test
that simple scenario. I just assumed it worked.
But, certainly, just a simple question from any maintainer about this
use-case could have helped solving this bug much earlier and saving time
to all the people it affected. I mean, it's not disappointing that it
took one month to get a fix. If the bug affected only my scenario that
would had been fine. It's disappointing that even if there was a single
_small_ 100% guilty patch, in one month, bug #1846557 did not get a
_single_ technical comment/question. We could have discovered this
broader-scope bug much earlier. It's not about fixing any bug "right
now" (bugs have priority). It's about at least talking with the reporter
and don't underestimate the scope of the bug, even if it appears to be
narrow. It might not be.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gdb in Ubuntu.
https://bugs.launchpad.net/bugs/1848200
Title:
gdb not stopping on breakpoint in a 32-bit program
Status in gdb package in Ubuntu:
Fix Released
Status in gdb source package in Bionic:
Fix Released
Bug description:
[Impact]
After upgrading gdb from 8.1-0ubuntu3 to 8.1-0ubuntu3.1, gdb does not stop
on breakpoint when running a 32-bit application (on 64-bit Ubuntu).
[Test Case]
This can be reproduced with a simple “hello world” program:
$ cat hello.c
#include
int main()
{
// printf() displays the string inside quotation
printf("Hello, World!");
return 0;
}
$ gcc -ggdb -m32 hello.c
$ gdb a.out
(gdb) b hello.c:5
Breakpoint 1 at 0x536: file hello.c, line 5.
(gdb) run
Starting program: /home/user/sandbox/a.out
warning: Breakpoint address adjusted from 0xf7fd9be0 to 0xf7fd9be0.
warning: Breakpoint address adjusted from 0xf7fda195 to 0xf7fda195.
warning: Breakpoint address adjusted from 0xf7fdbd1c to 0xf7fdbd1c.
warning: Breakpoint address adjusted from 0xf7fdb924 to 0xf7fdb924.
warning: Breakpoint address adjusted from 0xf7fe99b3 to 0xf7fe99b3.
warning: Breakpoint address adjusted from 0xf7fea401 to 0xf7fea401.
warning: Breakpoint address adjusted from 0xf7fea706 to 0xf7fea706.
--- (and not stopping nor outputting the text…) ---
[Regression Risk]
Test case ran on arm64 and regression tested using the above test case on
amd64, i386 and s390x.
This regression was fixed on the upstream gdb-8.1 branch within a few
weeks of the breakage back in May 2018. Since then there have been no
other fixes in this area on that branch, implying this fixed the issue
and there were no further regressions discovered.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1848200/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1846557] Re: Unable to debug any kernel on i386 qemu machine
A fix was released after bug #1848200, reporting the same problem, was opened. ** Changed in: gdb (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1846557 Title: Unable to debug any kernel on i386 qemu machine Status in gdb package in Ubuntu: Fix Released Bug description: Hi, On my x86_64 machine [running Ubuntu 18.04.3 LTS] with gdb version 'Ubuntu 8.1-0ubuntu3' I could happily debug any kernel running on a i386 qemu VM (qemu-system-i386) by just doing the following: > target remote localhost:1234 > b term.c:694 and then, when the breakpoint was hit I used to observe output like: > Breakpoint 1, term_action_use_alt_buffer (t=0xc017514c , use_alt_buffer=true) > at /home/vlad/dev/tilck/kernel/char/tty/term.c:694 And then I was able to do `s`, `si` or `c`, exactly like with regular user applications. With the newest update of gdb, version 'Ubuntu 8.1-0ubuntu3.1', instead, something is broken. By doing the same things I observe: > (gdb) b term.c:693 > warning: Breakpoint address adjusted from 0xc01158fe to 0xc01158fe. Which seems (and actually is) a bad sign, for what comes later. [why do you need to change the address? why do you want to extend it to 64-bit for a 32-bit machine?? mmm..] GDB detects the breakpoint, but in a weird way: Program received signal SIGTRAP, Trace/breakpoint trap. term_action_use_alt_buffer (t=0xc017514c , use_alt_buffer=true) At this point, I'm able to read the memory and the variables BUT, I cannot continue the execution, NOR doing any kind of step. The commands apparently don't get delivered to the remote side (QEMU), or they get delivered in a wrong way somehow. Example output: (gdb) b 709 warning: Breakpoint address adjusted from 0xc0115a45 to 0xc0115a45. Breakpoint 2 at 0xc0115a45: file /home/vlad/dev/tilck/kernel/char/tty/term.c, line 709. (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. term_action_use_alt_buffer (t=0xc017514c , use_alt_buffer=true) at /home/vlad/dev/tilck/kernel/char/tty/term.c:693 693t->alt_buf = kmalloc(sizeof(u16) * t->rows * t->cols); (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. term_action_use_alt_buffer (t=0xc017514c , use_alt_buffer=true) at /home/vlad/dev/tilck/kernel/char/tty/term.c:693 693t->alt_buf = kmalloc(sizeof(u16) * t->rows * t->cols); (gdb) c Continuing. As you see, the whole QEMU VM is stuck until I quit GDB. Note: I downgraded exclusively GDB back to version 'Ubuntu 8.1-0ubuntu3' in order to check if the problem would be fixed and it is. I'm sure the problem has been introduced in this specific version 'Ubuntu 8.1-0ubuntu3.1' and it's *not* related with QEMU *nor* with the kernel that is being debugged. It's totally independent from that. Final remark: note that I'm running gdb on x86_64 machine, while I'm debugging a kernel running on a i386 (virtual) machine. I believe that the cross-arch scenario almost certainly has something to do with the bug, as it happened in the past on both sides (qemu and gdb). Thanks a lot, Vlad To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1846557/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1848200] Re: gdb not stopping on breakpoint in a 32-bit program
*** This bug is a duplicate of bug 1846557 ***
https://bugs.launchpad.net/bugs/1846557
** This bug has been marked a duplicate of bug 1846557
Unable to debug any kernel on i386 qemu machine
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gdb in Ubuntu.
https://bugs.launchpad.net/bugs/1848200
Title:
gdb not stopping on breakpoint in a 32-bit program
Status in gdb package in Ubuntu:
Fix Released
Status in gdb source package in Bionic:
Fix Released
Bug description:
[Impact]
After upgrading gdb from 8.1-0ubuntu3 to 8.1-0ubuntu3.1, gdb does not stop
on breakpoint when running a 32-bit application (on 64-bit Ubuntu).
[Test Case]
This can be reproduced with a simple “hello world” program:
$ cat hello.c
#include
int main()
{
// printf() displays the string inside quotation
printf("Hello, World!");
return 0;
}
$ gcc -ggdb -m32 hello.c
$ gdb a.out
(gdb) b hello.c:5
Breakpoint 1 at 0x536: file hello.c, line 5.
(gdb) run
Starting program: /home/user/sandbox/a.out
warning: Breakpoint address adjusted from 0xf7fd9be0 to 0xf7fd9be0.
warning: Breakpoint address adjusted from 0xf7fda195 to 0xf7fda195.
warning: Breakpoint address adjusted from 0xf7fdbd1c to 0xf7fdbd1c.
warning: Breakpoint address adjusted from 0xf7fdb924 to 0xf7fdb924.
warning: Breakpoint address adjusted from 0xf7fe99b3 to 0xf7fe99b3.
warning: Breakpoint address adjusted from 0xf7fea401 to 0xf7fea401.
warning: Breakpoint address adjusted from 0xf7fea706 to 0xf7fea706.
--- (and not stopping nor outputting the text…) ---
[Regression Risk]
Test case ran on arm64 and regression tested using the above test case on
amd64, i386 and s390x.
This regression was fixed on the upstream gdb-8.1 branch within a few
weeks of the breakage back in May 2018. Since then there have been no
other fixes in this area on that branch, implying this fixed the issue
and there were no further regressions discovered.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1848200/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1846557] Re: Unable to debug any kernel on i386 qemu machine
Hi guys, any update on this? Just to be sure, I tried to the Linux kernel 4.19.16 in the same scenario and I got the same result. I built the kernel with buildroot and I launched QEMU with: qemu-system-i386 -kernel bzImage -S -s -append 'nokaslr' I know it needs an initrd and a hdd img in order to boot a full system, but for me it was enough to break on start_kernel and then trying to do `stepi`. Exactly like with the other project, with the gdb version `Ubuntu 8.1-0ubuntu3` it worked perfectly, while with gdb `Ubuntu 8.1-0ubuntu3.1` I got the same problem: (gdb) b start_kernel warning: Breakpoint address adjusted from 0xc17257cd to 0xc17257cd. Breakpoint 1 at 0xc17257cd (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0xc17257cd in start_kernel () (gdb) si 0xc17257cd in start_kernel () (gdb) si 0xc17257cd in start_kernel () (gdb) si 0xc17257cd in start_kernel () (gdb) si Therefore, as expected, the bug affects _definitively_ any kind of 32-bit code when remote debugging is used and the client is 64-bit. I also checked if the latest non-Ubuntu gdb is affected by this issue and it's not. In conclusion, I believe that the following patch introduced the regression: http://launchpadlibrarian.net/431301516/gdb_8.1-0ubuntu3_8.1-0ubuntu3.1.diff.gz And that the bug needs to get some attention. After all, people _cannot_ debug a 32-bit linux kernel running on a VM anymore, if they're using Ubuntu. @Manoj could you please comment? Thanks -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1846557 Title: Unable to debug any kernel on i386 qemu machine Status in gdb package in Ubuntu: New Bug description: Hi, On my x86_64 machine [running Ubuntu 18.04.3 LTS] with gdb version 'Ubuntu 8.1-0ubuntu3' I could happily debug any kernel running on a i386 qemu VM (qemu-system-i386) by just doing the following: > target remote localhost:1234 > b term.c:694 and then, when the breakpoint was hit I used to observe output like: > Breakpoint 1, term_action_use_alt_buffer (t=0xc017514c , use_alt_buffer=true) > at /home/vlad/dev/tilck/kernel/char/tty/term.c:694 And then I was able to do `s`, `si` or `c`, exactly like with regular user applications. With the newest update of gdb, version 'Ubuntu 8.1-0ubuntu3.1', instead, something is broken. By doing the same things I observe: > (gdb) b term.c:693 > warning: Breakpoint address adjusted from 0xc01158fe to 0xc01158fe. Which seems (and actually is) a bad sign, for what comes later. [why do you need to change the address? why do you want to extend it to 64-bit for a 32-bit machine?? mmm..] GDB detects the breakpoint, but in a weird way: Program received signal SIGTRAP, Trace/breakpoint trap. term_action_use_alt_buffer (t=0xc017514c , use_alt_buffer=true) At this point, I'm able to read the memory and the variables BUT, I cannot continue the execution, NOR doing any kind of step. The commands apparently don't get delivered to the remote side (QEMU), or they get delivered in a wrong way somehow. Example output: (gdb) b 709 warning: Breakpoint address adjusted from 0xc0115a45 to 0xc0115a45. Breakpoint 2 at 0xc0115a45: file /home/vlad/dev/tilck/kernel/char/tty/term.c, line 709. (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. term_action_use_alt_buffer (t=0xc017514c , use_alt_buffer=true) at /home/vlad/dev/tilck/kernel/char/tty/term.c:693 693t->alt_buf = kmalloc(sizeof(u16) * t->rows * t->cols); (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. term_action_use_alt_buffer (t=0xc017514c , use_alt_buffer=true) at /home/vlad/dev/tilck/kernel/char/tty/term.c:693 693t->alt_buf = kmalloc(sizeof(u16) * t->rows * t->cols); (gdb) c Continuing. As you see, the whole QEMU VM is stuck until I quit GDB. Note: I downgraded exclusively GDB back to version 'Ubuntu 8.1-0ubuntu3' in order to check if the problem would be fixed and it is. I'm sure the problem has been introduced in this specific version 'Ubuntu 8.1-0ubuntu3.1' and it's *not* related with QEMU *nor* with the kernel that is being debugged. It's totally independent from that. Final remark: note that I'm running gdb on x86_64 machine, while I'm debugging a kernel running on a i386 (virtual) machine. I believe that the cross-arch scenario almost certainly has something to do with the bug, as it happened in the past on both sides (qemu and gdb). Thanks a lot, Vlad To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1846557/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help
[Touch-packages] [Bug 1846557] [NEW] Unable to debug any kernel on i386 qemu machine
Public bug reported: Hi, On my x86_64 machine [running Ubuntu 18.04.3 LTS] with gdb version 'Ubuntu 8.1-0ubuntu3' I could happily debug any kernel running on a i386 qemu VM (qemu-system-i386) by just doing the following: > target remote localhost:1234 > b term.c:694 and then, when the breakpoint was hit I used to observe output like: > Breakpoint 1, term_action_use_alt_buffer (t=0xc017514c , > use_alt_buffer=true) > at /home/vlad/dev/tilck/kernel/char/tty/term.c:694 And then I was able to do `s`, `si` or `c`, exactly like with regular user applications. With the newest update of gdb, version 'Ubuntu 8.1-0ubuntu3.1', instead, something is broken. By doing the same things I observe: > (gdb) b term.c:693 > warning: Breakpoint address adjusted from 0xc01158fe to 0xc01158fe. Which seems (and actually is) a bad sign, for what comes later. [why do you need to change the address? why do you want to extend it to 64-bit for a 32-bit machine?? mmm..] GDB detects the breakpoint, but in a weird way: Program received signal SIGTRAP, Trace/breakpoint trap. term_action_use_alt_buffer (t=0xc017514c , use_alt_buffer=true) At this point, I'm able to read the memory and the variables BUT, I cannot continue the execution, NOR doing any kind of step. The commands apparently don't get delivered to the remote side (QEMU), or they get delivered in a wrong way somehow. Example output: (gdb) b 709 warning: Breakpoint address adjusted from 0xc0115a45 to 0xc0115a45. Breakpoint 2 at 0xc0115a45: file /home/vlad/dev/tilck/kernel/char/tty/term.c, line 709. (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. term_action_use_alt_buffer (t=0xc017514c , use_alt_buffer=true) at /home/vlad/dev/tilck/kernel/char/tty/term.c:693 693 t->alt_buf = kmalloc(sizeof(u16) * t->rows * t->cols); (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. term_action_use_alt_buffer (t=0xc017514c , use_alt_buffer=true) at /home/vlad/dev/tilck/kernel/char/tty/term.c:693 693 t->alt_buf = kmalloc(sizeof(u16) * t->rows * t->cols); (gdb) c Continuing. As you see, the whole QEMU VM is stuck until I quit GDB. Note: I downgraded exclusively GDB back to version 'Ubuntu 8.1-0ubuntu3' in order to check if the problem would be fixed and it is. I'm sure the problem has been introduced in this specific version 'Ubuntu 8.1-0ubuntu3.1' and it's *not* related with QEMU *nor* with the kernel that is being debugged. It's totally independent from that. Final remark: note that I'm running gdb on x86_64 machine, while I'm debugging a kernel running on a i386 (virtual) machine. I believe that the cross-arch scenario almost certainly has something to do with the bug, as it happened in the past on both sides (qemu and gdb). Thanks a lot, Vlad ** Affects: gdb (Ubuntu) Importance: Undecided Status: New ** Tags: bionic regression-update ** Description changed: Hi, On my x86_64 machine [running Ubuntu 18.04.3 LTS] with gdb version 'Ubuntu 8.1-0ubuntu3' I could happily debug any kernel running on a i386 qemu VM (qemu-system-i386) by just doing the following: > target remote localhost:1234 > b term.c:694 and then, when the breakpoint was hit I used to observe output like: > Breakpoint 1, term_action_use_alt_buffer (t=0xc017514c , use_alt_buffer=true) > at /home/vlad/dev/tilck/kernel/char/tty/term.c:694 And then I was able to do `s`, `si` or `c`, exactly like with regular user applications. With the newest update of gdb, version 'Ubuntu 8.1-0ubuntu3.1', instead, something is broken. By doing the same things I observe: > (gdb) b term.c:693 > warning: Breakpoint address adjusted from 0xc01158fe to 0xc01158fe. - Which seems (and actually is a bad sign), for what comes later. [why do + Which seems (and actually is) a bad sign, for what comes later. [why do you need to change the address? why do you want to extend it to 64-bit for a 32-bit machine?? mmm..] GDB detects the breakpoint, but in a weird way: Program received signal SIGTRAP, Trace/breakpoint trap. term_action_use_alt_buffer (t=0xc017514c , use_alt_buffer=true) At this point, I'm able to read the memory and the variables BUT, I cannot continue the execution, NOR doing any kind of step. The commands apparently don't get delivered to the remote side (QEMU), or they get delivered in a wrong way somehow. Example output: (gdb) b 709 warning: Breakpoint address adjusted from 0xc0115a45 to 0xc0115a45. Breakpoint 2 at 0xc0115a45: file /home/vlad/dev/tilck/kernel/char/tty/term.c, line 709. (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. term_action_use_alt_buffer (t=0xc017514c , use_alt_buffer=true) - at /home/vlad/dev/tilck/kernel/char/tty/term.c:693 + at /home/vlad/dev/tilck/kernel/char/tty/term.c:693 693t->alt_buf = kmalloc(sizeof(u16) *
