From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129841 invoked by alias); 21 Feb 2019 11:21:38 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 129804 invoked by uid 89); 21 Feb 2019 11:21:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=HTo:U*gdb, H*Ad:U*gdb, 12502, flight X-HELO: mail-it1-f177.google.com Received: from mail-it1-f177.google.com (HELO mail-it1-f177.google.com) (209.85.166.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 21 Feb 2019 11:21:36 +0000 Received: by mail-it1-f177.google.com with SMTP id l15so22216806iti.4 for ; Thu, 21 Feb 2019 03:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=undo-io.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=+dHERn7SwefJPQRqb6Dgt2inqHegw5K9ia1nuCcaX2Q=; b=cJB4ubEaRVG8+RF/k7xGn3jdrj5ab4q4SACRx0FmUFSgx7Ah8bNO+HTVN45znrTwFT EvamTKK9mRYLWbgaEESsdfqgoq19y3bBSAlp5mujpkcE5kuWhuu0lUh+fjoERYTuq+1Z o6aesFRCWHKt3MPzKijpGU2pq45NQr1SImE2ULoOEfKBmfFQ57liyF0oV4prReppxQqF UQMoKxQz78Dp4Al87kQfsn/3iLGY/srRL+J4tT9thh69llrrUZr8XOweykgnnrIEgkAg bxm8HyP6TvcJjZ7KS8SND+49rYAZghkTr1oYWjjLg3tSn+Lii5bWPNBJAk8Wq4lIGjVU 0Chg== MIME-Version: 1.0 From: David Griffiths Date: Thu, 21 Feb 2019 11:21:00 -0000 Message-ID: Subject: "finish" command leads to SIGTRAP To: gdb@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg00037.txt.bz2 I have a strange situation where issuing the "finish" command always leads to a SIGTRAP (this is gdb 8.1 on Ubuntu 16.04). Once this SIGTRAP occurs every continue also produces SIGTRAP. Completely reproducible. In the run up to the finish I'm doing single steps from a previous breakpoint: ===== (gdb) display/i $pc 1: x/i $pc => 0x7fffe1923b84: movabs $0x7ffff6d33b00,%r10 (gdb) si 0x00007fffe1923b8e in ?? () 1: x/i $pc => 0x7fffe1923b8e: callq *%r10 (gdb) 0x00007ffff6d33b00 in os::javaTimeMillis() () from /mnt/hgfs/david/jdk8u/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so 1: x/i $pc => 0x7ffff6d33b00 <_ZN2os14javaTimeMillisEv>: push %rbp (gdb) finish Run till exit from #0 0x00007ffff6d33b00 in os::javaTimeMillis() () from /mnt/hgfs/david/jdk8u/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so Thread 2 "java" received signal SIGTRAP, Trace/breakpoint trap. 0x00007ffff6d33b01 in os::javaTimeMillis() () from /mnt/hgfs/david/jdk8u/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so 1: x/i $pc => 0x7ffff6d33b01 <_ZN2os14javaTimeMillisEv+1>: xor %esi,%esi (gdb) c Continuing. Thread 2 "java" received signal SIGTRAP, Trace/breakpoint trap. 0x00007ffff6d33b03 in os::javaTimeMillis() () from /mnt/hgfs/david/jdk8u/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so 1: x/i $pc => 0x7ffff6d33b03 <_ZN2os14javaTimeMillisEv+3>: mov %rsp,%rbp ===== Even more strangely I can execute finish on that function in general, e.g. if I set a breakpoint on it: ===== (gdb) br os::javaTimeMillis Breakpoint 1 at 0x7ffff6d33b00 (gdb) c Continuing. [Switching to Thread 0x7ffff7fd8700 (LWP 12502)] Thread 2 "java" hit Breakpoint 1, 0x00007ffff6d33b00 in os::javaTimeMillis() () from /mnt/hgfs/david/jdk8u/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so (gdb) finish Run till exit from #0 0x00007ffff6d33b00 in os::javaTimeMillis() () from /mnt/hgfs/david/jdk8u/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so 0x00007fffe1b4f75c in ?? () (gdb) ===== So there must be something about the environment when it occurs but I don't know what. And by the way the code runs fine without the finish/single steps/etc. I need it to work because I'm trying to automate something via gdb/MI. Any suggestions as to how to debug this would be very welcome. Thanks, David -- David Griffiths, Senior Software Engineer Undo | Resolve even the most challenging software defects with software flight recorder technology Software reliability report: optimizing the software supplier and customer relationship