| 2016-11-28 23:05:33 |
Brian Murray |
bug |
|
|
added bug |
| 2016-11-29 19:15:36 |
Brian Murray |
bug watch added |
|
https://bugzilla.redhat.com/show_bug.cgi?id=1196181 |
|
| 2016-11-30 23:48:18 |
Brian Murray |
attachment added |
|
gdb_7.12-0ubuntu3.debdiff https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1645501/+attachment/4785470/+files/gdb_7.12-0ubuntu3.debdiff |
|
| 2016-11-30 23:48:47 |
Brian Murray |
attachment added |
|
gdb_7.11.90.20161005-0ubuntu1.1.debdiff https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1645501/+attachment/4785471/+files/gdb_7.11.90.20161005-0ubuntu1.1.debdiff |
|
| 2016-11-30 23:52:08 |
Brian Murray |
gdb (Ubuntu): importance |
Undecided |
High |
|
| 2016-11-30 23:52:11 |
Brian Murray |
gdb (Ubuntu): status |
New |
Triaged |
|
| 2016-12-01 00:32:37 |
Ubuntu Foundations Team Bug Bot |
tags |
|
patch |
|
| 2016-12-02 19:09:22 |
Brian Murray |
gdb (Ubuntu): assignee |
|
Brian Murray (brian-murray) |
|
| 2016-12-02 19:12:30 |
Brian Murray |
nominated for series |
|
Ubuntu Yakkety |
|
| 2016-12-02 19:12:30 |
Brian Murray |
bug task added |
|
gdb (Ubuntu Yakkety) |
|
| 2016-12-02 19:12:30 |
Brian Murray |
nominated for series |
|
Ubuntu Precise |
|
| 2016-12-02 19:12:30 |
Brian Murray |
bug task added |
|
gdb (Ubuntu Precise) |
|
| 2016-12-02 19:12:30 |
Brian Murray |
nominated for series |
|
Ubuntu Trusty |
|
| 2016-12-02 19:12:30 |
Brian Murray |
bug task added |
|
gdb (Ubuntu Trusty) |
|
| 2016-12-02 19:12:30 |
Brian Murray |
nominated for series |
|
Ubuntu Xenial |
|
| 2016-12-02 19:12:30 |
Brian Murray |
bug task added |
|
gdb (Ubuntu Xenial) |
|
| 2016-12-02 19:13:01 |
Brian Murray |
gdb (Ubuntu Precise): status |
New |
Triaged |
|
| 2016-12-02 19:13:04 |
Brian Murray |
gdb (Ubuntu Trusty): status |
New |
Triaged |
|
| 2016-12-02 19:13:28 |
Brian Murray |
gdb (Ubuntu Xenial): status |
New |
Triaged |
|
| 2016-12-02 19:13:32 |
Brian Murray |
gdb (Ubuntu Yakkety): status |
New |
Triaged |
|
| 2016-12-02 19:30:51 |
Brian Murray |
description |
I'm filing this about gdb per Steve's suggestion, although this could be an issue somewhere else.
I recently discovered that the apport-test-crash (https://code.launchpad.net/~daisy-pluckers/error-tracker-deployment/test-crashes) crash files produced for armhf are crash files without CoreDumps. This happened sometime between 20160531 and 20161025. I've recreated this on the porter-arm64 box with the following minimal test case (generate-sigsegv-crash.py is from apport-test-crashes):
schroot -c yakkety-armhf
python generate-sigsegv-crash.py cat
Running this on both armhf and arm64 we can see the following different output.
armhf chroot on porter-armhf:
47 Program received signal SIGSEGV, Segmentation fault.
48 0xb6f599e4 in read () at ../sysdeps/unix/syscall-template.S:84
49 84 ../sysdeps/unix/syscall-template.S: No such file or directory.
50 (gdb) Saved corefile /tmp/tmp840s08i1/my.core
armhf chroot on porter-arm64:
47 Program received signal SIGSEGV, Segmentation fault.
48 0xf772f9e4 in read () at ../sysdeps/unix/syscall-template.S:84
49 84 ../sysdeps/unix/syscall-template.S: No such file or directory.
50 (gdb) Unable to fetch the floating point registers.: Invalid argument.
Notice how there is no core file save on porter-arm64. |
Impact
------
Its not possible to create a corefile in an armhf chroot on an arm64 system.
Test Case
---------
On an arm64 system enter an armhf chroot, then
1) execute "gdb --args cat"
2) in gdb type run
3) press Ctrl-Z
4) generate-core-file /tmp/my.core
With the current version of gdb you'll see "Unable to fetch floating point registers.", with the version in -proposed you'll see "Saved corefile".
Regression Potential
--------------------
I'm not quite sure.
I'm filing this about gdb per Steve's suggestion, although this could be an issue somewhere else.
I recently discovered that the apport-test-crash (https://code.launchpad.net/~daisy-pluckers/error-tracker-deployment/test-crashes) crash files produced for armhf are crash files without CoreDumps. This happened sometime between 20160531 and 20161025. I've recreated this on the porter-arm64 box with the following minimal test case (generate-sigsegv-crash.py is from apport-test-crashes):
schroot -c yakkety-armhf
python generate-sigsegv-crash.py cat
Running this on both armhf and arm64 we can see the following different output.
armhf chroot on porter-armhf:
47 Program received signal SIGSEGV, Segmentation fault.
48 0xb6f599e4 in read () at ../sysdeps/unix/syscall-template.S:84
49 84 ../sysdeps/unix/syscall-template.S: No such file or directory.
50 (gdb) Saved corefile /tmp/tmp840s08i1/my.core
armhf chroot on porter-arm64:
47 Program received signal SIGSEGV, Segmentation fault.
48 0xf772f9e4 in read () at ../sysdeps/unix/syscall-template.S:84
49 84 ../sysdeps/unix/syscall-template.S: No such file or directory.
50 (gdb) Unable to fetch the floating point registers.: Invalid argument.
Notice how there is no core file save on porter-arm64. |
|
| 2016-12-02 19:33:02 |
Brian Murray |
gdb (Ubuntu Yakkety): assignee |
|
Brian Murray (brian-murray) |
|
| 2016-12-02 19:33:06 |
Brian Murray |
gdb (Ubuntu Yakkety): importance |
Undecided |
Medium |
|
| 2016-12-02 19:33:09 |
Brian Murray |
gdb (Ubuntu Xenial): importance |
Undecided |
Medium |
|
| 2016-12-02 19:33:11 |
Brian Murray |
gdb (Ubuntu Trusty): importance |
Undecided |
Medium |
|
| 2016-12-02 19:33:14 |
Brian Murray |
gdb (Ubuntu Precise): importance |
Undecided |
Medium |
|
| 2016-12-02 19:43:52 |
Brian Murray |
gdb (Ubuntu Precise): status |
Triaged |
Invalid |
|
| 2016-12-06 11:40:14 |
Launchpad Janitor |
gdb (Ubuntu): status |
Triaged |
Fix Released |
|
| 2016-12-12 17:05:03 |
Brian Murray |
gdb (Ubuntu Trusty): assignee |
|
Brian Murray (brian-murray) |
|
| 2016-12-12 17:05:06 |
Brian Murray |
gdb (Ubuntu Xenial): assignee |
|
Brian Murray (brian-murray) |
|
| 2017-01-27 19:45:02 |
Brian Murray |
description |
Impact
------
Its not possible to create a corefile in an armhf chroot on an arm64 system.
Test Case
---------
On an arm64 system enter an armhf chroot, then
1) execute "gdb --args cat"
2) in gdb type run
3) press Ctrl-Z
4) generate-core-file /tmp/my.core
With the current version of gdb you'll see "Unable to fetch floating point registers.", with the version in -proposed you'll see "Saved corefile".
Regression Potential
--------------------
I'm not quite sure.
I'm filing this about gdb per Steve's suggestion, although this could be an issue somewhere else.
I recently discovered that the apport-test-crash (https://code.launchpad.net/~daisy-pluckers/error-tracker-deployment/test-crashes) crash files produced for armhf are crash files without CoreDumps. This happened sometime between 20160531 and 20161025. I've recreated this on the porter-arm64 box with the following minimal test case (generate-sigsegv-crash.py is from apport-test-crashes):
schroot -c yakkety-armhf
python generate-sigsegv-crash.py cat
Running this on both armhf and arm64 we can see the following different output.
armhf chroot on porter-armhf:
47 Program received signal SIGSEGV, Segmentation fault.
48 0xb6f599e4 in read () at ../sysdeps/unix/syscall-template.S:84
49 84 ../sysdeps/unix/syscall-template.S: No such file or directory.
50 (gdb) Saved corefile /tmp/tmp840s08i1/my.core
armhf chroot on porter-arm64:
47 Program received signal SIGSEGV, Segmentation fault.
48 0xf772f9e4 in read () at ../sysdeps/unix/syscall-template.S:84
49 84 ../sysdeps/unix/syscall-template.S: No such file or directory.
50 (gdb) Unable to fetch the floating point registers.: Invalid argument.
Notice how there is no core file save on porter-arm64. |
Impact
------
Its not possible to create a corefile in an armhf chroot on an arm64 system.
Test Case
---------
On an arm64 system enter an armhf chroot, then
1) execute "gdb --args cat"
2) in gdb type run
3) press Ctrl-Z
4) generate-core-file /tmp/my.core
With the current version of gdb you'll see "Unable to fetch floating point registers.", with the version in -proposed you'll see "Saved corefile".
Regression Potential
--------------------
The corefiles aren't created at all in this scenario so things should improve.
I'm filing this about gdb per Steve's suggestion, although this could be an issue somewhere else.
I recently discovered that the apport-test-crash (https://code.launchpad.net/~daisy-pluckers/error-tracker-deployment/test-crashes) crash files produced for armhf are crash files without CoreDumps. This happened sometime between 20160531 and 20161025. I've recreated this on the porter-arm64 box with the following minimal test case (generate-sigsegv-crash.py is from apport-test-crashes):
schroot -c yakkety-armhf
python generate-sigsegv-crash.py cat
Running this on both armhf and arm64 we can see the following different output.
armhf chroot on porter-armhf:
47 Program received signal SIGSEGV, Segmentation fault.
48 0xb6f599e4 in read () at ../sysdeps/unix/syscall-template.S:84
49 84 ../sysdeps/unix/syscall-template.S: No such file or directory.
50 (gdb) Saved corefile /tmp/tmp840s08i1/my.core
armhf chroot on porter-arm64:
47 Program received signal SIGSEGV, Segmentation fault.
48 0xf772f9e4 in read () at ../sysdeps/unix/syscall-template.S:84
49 84 ../sysdeps/unix/syscall-template.S: No such file or directory.
50 (gdb) Unable to fetch the floating point registers.: Invalid argument.
Notice how there is no core file save on porter-arm64. |
|
| 2017-02-02 18:03:32 |
Brian Murray |
gdb (Ubuntu Yakkety): status |
Triaged |
Fix Committed |
|
| 2017-02-02 18:03:34 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2017-02-02 18:03:38 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2017-02-02 18:03:45 |
Brian Murray |
tags |
patch |
patch verification-needed |
|
| 2017-04-17 17:29:11 |
Brian Murray |
tags |
patch verification-needed |
patch verification-done |
|
| 2017-04-17 17:45:12 |
Launchpad Janitor |
gdb (Ubuntu Yakkety): status |
Fix Committed |
Fix Released |
|
| 2017-04-17 17:45:20 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
