Running gdb causes "alignment check: 0000" error on 64-bit EC2 t1.micro instances

[Richard Marks]

I am unable to run gdb successfully on an Oneiric EC2 t1.micro 64-bit instance. The simplest case for reproducing this issue is to use "gdb /bin/true" and then the "run" command. gdb will hang and an "alignment check: 0000" from the kernel will appear in the dmesg output (full message included in the included debug info).

This only seems to happen on EC2 t1.micro 64-bit instances in my limited testing. 32-bit instances seem to be OK, along with larger 64-bit instances.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: linux-image-3.0.0-12-virtual 3.0.0-12.20
ProcVersionSignature: User Name 3.0.0-12.20-virtual 3.0.4
Uname: Linux 3.0.0-12-virtual x86_64
AlsaDevices:
 total 0
 crw-rw---- 1 root audio 116, 1 2011-10-31 11:21 seq
 crw-rw---- 1 root audio 116, 33 2011-10-31 11:21 timer
AplayDevices: Error: [Errno 2] No such file or directory
ApportVersion: 1.23-0ubuntu3
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory
Date: Mon Oct 31 11:43:51 2011
Ec2AMI: ami-bbf539d2
Ec2AMIManifest: (unknown)
Ec2AvailabilityZone: us-east-1c
Ec2InstanceType: t1.micro
Ec2Kernel: aki-825ea7eb
Ec2Ramdisk: unavailable
Lspci:

Lsusb: Error: command ['lsusb'] failed with exit code 1: unable to initialize libusb: -99
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: root=LABEL=cloudimg-rootfs ro console=hvc0
ProcModules: acpiphp 24080 0 - Live 0x0000000000000000
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
---
AlsaDevices:
 total 0
 crw-rw---- 1 root audio 116, 1 2011-10-31 20:32 seq
 crw-rw---- 1 root audio 116, 33 2011-10-31 20:32 timer
AplayDevices: Error: [Errno 2] No such file or directory
ApportVersion: 1.23-0ubuntu3
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory
DistroRelease: Ubuntu 11.10
Ec2AMI: ami-bbf539d2
Ec2AMIManifest: (unknown)
Ec2AvailabilityZone: us-east-1c
Ec2InstanceType: t1.micro
Ec2Kernel: aki-825ea7eb
Ec2Ramdisk: unavailable
Lspci:

Lsusb: Error: command ['lsusb'] failed with exit code 1: unable to initialize libusb: -99
Package: linux (not installed)
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: root=LABEL=cloudimg-rootfs ro console=hvc0
ProcModules: acpiphp 24080 0 - Live 0x0000000000000000
ProcVersionSignature: User Name 3.0.0-12.20-virtual 3.0.4
Tags: oneiric ec2-images
Uname: Linux 3.0.0-12-virtual x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm admin audio cdrom dialout dip floppy netdev plugdev video

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 884181

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Richard Marks (richmarks)]

apport information

[Richard Marks (richmarks)]

apport information

[Richard Marks (richmarks)]

apport information

[Richard Marks (richmarks)]

apport information

[Richard Marks (richmarks)]

apport information

[Richard Marks (richmarks)]

apport information

[Richard Marks (richmarks)]

After some further playing around I'm able to reproduce this on the affected instance type with the following code:

#include <unistd.h>
#include <signal.h>

int main(void) {
  pid_t pid;

  pid = fork();
  if (pid == 0) {
    sleep(50);
  } else {
    kill(pid, SIGTERM);
  }
}

[Cesar A. Longoria II (ca2longoria)]

Hello. Did you ever find a solution to this problem? That same code results in similar errors on my EC2 Instance. Thank you.

[Cesar A. Longoria II (ca2longoria)]

Well, for any running into this same issue with the unexplainable kernel spew, I've found a way around it. It seems if a fork sleeps for >= 1 microsecond (0.000001 seconds) immediately after creation, all proceeds normally (this value may vary). Any less, and it vomits. This would appear to have something to do with the EC2 hypervisor's inner workings, at the hardware or kernel level methinks.