Bug 29871 - "p tail.y ++ (diff.y / 2)" command causes crash
Summary: "p tail.y ++ (diff.y / 2)" command causes crash
Status: RESOLVED FIXED
Alias: None
Product: gdb
Classification: Unclassified
Component: gdb (show other bugs)
Version: 12.1
: P2 normal
Target Milestone: 13.1
Assignee: Tom Tromey
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-12-10 21:03 UTC by George Bateman
Modified: 2023-03-20 14:45 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed: 2022-12-10 00:00:00


Attachments
GDB session resulting in crash (2.12 KB, text/plain)
2022-12-10 21:03 UTC, George Bateman
Details

Note You need to log in before you can comment on or make changes to this bug.
Description George Bateman 2022-12-10 21:03:15 UTC
Created attachment 14491 [details]
GDB session resulting in crash

While debugging a C application I entered the command "p tail.y ++ (diff.y / 2)". (This was a typo; I intended to write "+=".) This caused GDB to crash and output the attached backtrace, starting with:

/build/gdb-YpKTRx/gdb-12.1/gdb/gdbtypes.c:3914: internal-error: is_nocall_function: Assertion `type->code () == TYPE_CODE_FUNC || type->code () == TYPE_CODE_METHOD' failed.

The tail and diff objects are instances of the below struct, if that is relevant.

typedef struct {
    int x;
    int y;
} coord;

System information (also in the attachment):

GCC VERSION

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 12.2.0-9' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-12 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-12-lH3g9c/gcc-12-12.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-lH3g9c/gcc-12-12.2.0/debian/tmp-gcn/usr --enable-offload-defaulted --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Debian 12.2.0-9) 

Linux gbat-hp-linux 6.0.0-4-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.0.8-1 (2022-11-11) x86_64 GNU/Linux
Comment 1 Simon Marchi 2022-12-10 22:30:06 UTC
I can reproduce.  I used this source code:

typedef struct {
    int x;
    int y;
} coord;

int main()
{
  coord tail, diff;

  return tail.x + diff.x;
}
Comment 3 Sourceware Commits 2022-12-13 05:03:34 UTC
The master branch has been updated by Tom Tromey <tromey@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=785545988c222f603a7a190170b04d4b971d7959

commit 785545988c222f603a7a190170b04d4b971d7959
Author: Tom Tromey <tom@tromey.com>
Date:   Sun Dec 11 12:48:07 2022 -0700

    Fix crash in is_nocall_function
    
    is_nocall_function anticipates only being called for a function or a
    method.  However, PR gdb/29871 points out a situation where an unusual
    expression -- but one that parses to a valid, if extremely weird,
    function call -- breaks this assumption.
    
    This patch changes is_nocall_function to remove this assert and
    instead simply return 'false' in this case.
    
    Approved-By: Simon Marchi <simon.marchi@efficios.com>
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29871
Comment 4 Tom Tromey 2022-12-13 05:04:42 UTC
Fixed.
Comment 5 Alexandr Miloslavskiy 2023-03-20 14:45:05 UTC
The problem was standing in my way in a completely useful usecase.

I was calling a function like this:
(gdb) call (void)0x00007ffff6e072a0()

The reason for calling it by address is that there is an ambiguous symbol name for it:
1) libgcrypt.so - ps - some variable
2) libjvm.so    - ps - function I want to call, exported as non-debugging symbol

And I didn't find a way to disambiguate them, see
https://sourceware.org/pipermail/gdb/2021-September/049677.html