[Bug 1645501] Re: corefiles not created in armhf chroot on arm64 porter

[Brian Murray]

** Description changed:

- I'm filing this about gdb per Steve's suggestion, although this could be
- an issue somewhere else.
+ 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
+   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.
+   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.

** Changed in: gdb (Ubuntu Yakkety)
     Assignee: (unassigned) => Brian Murray (brian-murray)

** Changed in: gdb (Ubuntu Yakkety)
   Importance: Undecided => Medium

** Changed in: gdb (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: gdb (Ubuntu Trusty)
   Importance: Undecided => Medium

** Changed in: gdb (Ubuntu Precise)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to gdb in Ubuntu.
https://bugs.launchpad.net/bugs/1645501

Title:
  corefiles not created in armhf chroot on arm64 porter

Status in gdb package in Ubuntu:
  Triaged
Status in gdb source package in Precise:
  Triaged
Status in gdb source package in Trusty:
  Triaged
Status in gdb source package in Xenial:
  Triaged
Status in gdb source package in Yakkety:
  Triaged

Bug 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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1645501/+subscriptions