Comment 0 for bug 1545401

I was trying to attach gdb to chromium-browser, by passing the PID to gdb (gdb -p $PID). The first attempt as non-root user crashed gdb, then I tried running it as root (sudo gdb -p $PID). gdb got stuck at "Attaching to process ..." and I got this message:

------------[ cut here ]------------
kernel BUG at /build/linux-lts-wily-Vv6Eyd/linux-lts-wily-4.2.0/mm/memory.c:3146!
invalid opcode: 0000 [#1] SMP
Modules linked in: vboxpci(OE) vboxnetadp(OE) r8168(OE) vboxnetflt(OE) vboxdrv(OE) ib_cm ib_sa ib_mad ib_core ib_addr libfc qla2xxx scsi_transport_fc configfs pci_stub drbg ansi_cprng ctr ccm dm_crypt ip6table_filter ip6_tables iptable_filter ip_tables x_tables binfmt_misc uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev media arc4 hp_wmi sparse_keymap rtsx_pci_ms memstick dm_multipath scsi_dh snd_hda_codec_idt ath9k snd_hda_codec_generic ath9k_common snd_hda_codec_hdmi joydev ath9k_hw input_leds snd_hda_intel serio_raw ath snd_hda_codec snd_hda_core snd_hwdep k10temp snd_pcm_oss mac80211 snd_mixer_oss snd_pcm snd_seq_midi i2c_piix4 snd_seq_midi_event snd_rawmidi cfg80211 snd_seq snd_seq_device snd_timer snd soundcore shpchp parport_pc hp_accel lis3lv02d ppdev input_polldev mac_hid cpuid msr ircomm_tty ircomm irda crc_ccitt lp parport btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq raid1 raid0 multipath linear pata_acpi rtsx_pci_sdmmc amdkfd amd_iommu_v2 radeon i2c_algo_bit ttm drm_kms_helper psmouse ahci drm pata_atiixp libahci rtsx_pci wmi video [last unloaded: vboxpci]
CPU: 3 PID: 25702 Comm: gdb Tainted: G OE 4.2.0-27-generic #32~14.04.1-Ubuntu
Hardware name: Hewlett-Packard HP Pavilion dv6 Notebook PC/3590, BIOS F.21 09/13/2011
task: ffff8800cb54d780 ti: ffff88000a8f0000 task.ti: ffff88000a8f0000
RIP: 0010:[<ffffffff811a6a90>] [<ffffffff811a6a90>] handle_mm_fault+0x17e0/0x1840
RSP: 0018:ffff88000a8f3bb8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00003ffffffff000
RDX: ffff8801697c04f8 RSI: 0000000000000120 RDI: 00000001697c0067
RBP: ffff88000a8f3c78 R08: 00000001edddb120 R09: 0000000000000120
R10: 0000000000000001 R11: ffff8800000004f8 R12: ffff88003265bc00
R13: ffff880007a18808 R14: 00007f856029fe68 R15: ffff8800aa3843c0
FS: 00007f3d95334740(0000) GS:ffff88020ed80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000002b69528 CR3: 000000012a9ad000 CR4: 00000000000006e0
Stack:
 0000001600000000 ffff880000000016 ffffea0005a5f030 ffffffff817b0e73
 ffff88003265bc00 00007f856029fe68 0000001700000000 ffff8800000004f8
 ffff880000000000 0000000000000017 00007f856029fe68 ffff88003265bc00
Call Trace:
 [<ffffffff817b0e73>] ? follow_page_pte+0xae/0x307
 [<ffffffff811a070e>] ? follow_page_mask+0x1ce/0x320
 [<ffffffff811a095b>] __get_user_pages+0xfb/0x5b0
 [<ffffffff811a1222>] get_user_pages+0x52/0x60
 [<ffffffff811a16a7>] __access_remote_vm+0xb7/0x1c0
 [<ffffffff811a7620>] access_process_vm+0x50/0x70
 [<ffffffff81081aa9>] ptrace_request+0x2c9/0x5a0
 [<ffffffff817ae9da>] ? queued_spin_lock_slowpath+0xb/0xf
 [<ffffffff810a0efa>] ? wait_task_inactive+0xea/0x1e0
 [<ffffffff811eb508>] ? vfs_write+0x148/0x190
 [<ffffffff81022f51>] arch_ptrace+0x261/0x2b0
 [<ffffffff81080a2f>] ? ptrace_check_attach+0x5f/0x140
 [<ffffffff81081726>] SyS_ptrace+0xa6/0x110
 [<ffffffff817bc3b2>] entry_SYSCALL_64_fastpath+0x16/0x75
Code: d8 50 a8 81 e8 92 0f ed ff 4c 8b 9d 78 ff ff ff e9 fa ee ff ff 48 8b 7d 98 89 45 80 e8 2a dd fd ff 8b 45 80 89 c3 e9 ba eb ff ff <0f> 0b c7 45 80 01 00 00 00 e9 a5 f7 ff ff 4c 89 c7 48 89 95 68
RIP [<ffffffff811a6a90>] handle_mm_fault+0x17e0/0x1840
 RSP <ffff88000a8f3bb8>
---[ end trace c5ec208e5d4b9c66 ]---

Then, I tried killing gdb as root from another terminal, by running "killall gdb", but killall got stuck, too. pidof and ps also got stuck...

This is the line referenced in the error message: http://lxr.free-electrons.com/source/mm/memory.c?v=4.2#L3146 , I'm not sure if Ubuntu runs a modified version of this file, though. Also, I'm not sure if this affects Wily (I guess it does) or if this has been patched upstream.

There is a similar bug report here: https://bugzilla.redhat.com/show_bug.cgi?id=1296505 , but it doesn't involve gdb.

Should I report this bug upstream?