Bug 27757

Created attachment 13388 [details]
gdb transcript

Created attachment 13389 [details]
compiled binary

-var-list-children coredumps GDB

If I set a breakpoint at line 13 and run, then this command

0-interpreter-exec --thread 1 --frame 0 mi2 "-var-create var1_b * \"b\""

causes a crash for me.

Now I think that the crash I see is new & different
from the one reported in this bug.

... but now I see this new crash in 10.x, so I think we're in trouble.

FWIW if I remove the "interpreter-exec" wrapper stuff (which is
a bit surprising to see...), I can't reproduce the original bug
on Linux anyway.  I didn't try Windows.

Might the crash be related to some pretty printer?

(In reply to Tom Tromey from comment #4)
> If I set a breakpoint at line 13 and run, then this command
> 
> 0-interpreter-exec --thread 1 --frame 0 mi2 "-var-create var1_b * \"b\""
> 
> causes a crash for me.

What interpreter do you start GDB with?  If I start it with -i=mi (equivalent to -i=mi3), I get a crash too.  So it seems GDB doesn't like that you use interpreter-exec with a different MI interpreter than the current one.

(In reply to Elmot from comment #0)
> Created attachment 13387 [details]
> main.c
> 
> Coredump report from our customer
> GDB 10.1
> GCC 9.2

I would like to investigate this, especially since it hits an assert that I introduced (it may be a bug introduced by my patch, or my patch might just uncover an existing bug).  But I am really not nicely set up to develop on Windows, so it will take some time.  If you find a way to reproduce on Linux, please share!

In fact the original reporter (a CLion user) run into the bug on Linux
CLion works as a gdb frontend, so that's why -mi is used and some commands look not so humanoid
https://youtrack.jetbrains.com/issue/CPP-24874

I have reproduced that on Win, that's why I did not report the OS.
I'll try to reproduce the same under Linux or at least under WSL.

Created attachment 13395 [details]
Ubuntu/x86_64 the bug reproduction

Here you are, apparently gdb crashes in pretty-printers

(In reply to Elmot from comment #12)
> Created attachment 13395 [details]
> Ubuntu/x86_64 the bug reproduction
> 
> Here you are, apparently gdb crashes in pretty-printers

Thanks, I can reproduce with this.

(gdb) 
-var-list-children --all-values "var1_b" -1 -1
~"/home/simark/src/binutils-gdb/gdb/gdbtypes.h:435: internal-error: LONGEST dynamic_prop::const_val() const: Assertion `m_kind == PROP_CONST' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.\nQuit this debugging session? (y or n) "

Ok, so the problem is quite simple: the flexible array member strikes again.

The reproducer can be simplified as:

struct foo {
    int len;
    int items[];
};

struct foo *p;

int main() {
    return 0;
}


and:

$ ./gdb -q -nx --data-directory=data-directory ./test -ex 'python gdb.parse_and_eval("p").type.target()["items"].type.range()'
Reading symbols from ./test...
/home/simark/src/binutils-gdb/gdb/gdbtypes.h:435: internal-error: LONGEST dynamic_prop::const_val() const: Assertion `m_kind == PROP_CONST' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) 

A similar fix with a test case was added here:

https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=5b56203a7cadd545b33713e98e274e582242e090

But a similar thing needs to be done for Python, I'll prepare a patch.

The master branch has been updated by Simon Marchi <simark@sourceware.org>:

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

commit e25d6d93c4a0d597da2521c2c38cb1ce6e51feb8
Author: Simon Marchi <simon.marchi@polymtl.ca>
Date:   Thu Apr 22 15:01:28 2021 -0400

    gdb: fix getting range of flexible array member in Python
    
    As reported in bug 27757, we get an internal error when doing:
    
        $ cat test.c
        struct foo {
            int len;
            int items[];
        };
    
        struct foo *p;
    
        int main() {
            return 0;
        }
        $ gcc test.c -g -O0 -o test
        $ ./gdb -q -nx --data-directory=data-directory ./test -ex 'python gdb.parse_and_eval("p").type.target()["items"].type.range()'
        Reading symbols from ./test...
        /home/simark/src/binutils-gdb/gdb/gdbtypes.h:435: internal-error: LONGEST dynamic_prop::const_val() const: Assertion `m_kind == PROP_CONST' failed.
        A problem internal to GDB has been detected,
        further debugging may prove unreliable.
        Quit this debugging session? (y or n)
    
    This is because the Python code (typy_range) blindly reads the high
    bound of the type of `items` as a constant value.  Since it is a
    flexible array member, it has no high bound, the property is undefined.
    Since commit 8c2e4e0689 ("gdb: add accessors to struct dynamic_prop"),
    the getters check that you are not getting a property value of the wrong
    kind, so this causes a failed assertion.
    
    Fix it by checking if the property is indeed a constant value before
    accessing it as such.  Otherwise, use 0.  This restores the previous GDB
    behavior: because the structure was zero-initialized, this is what was
    returned before.  But now this behavior is explicit and not accidental.
    
    Add a test, gdb.python/flexible-array-member.exp, that is derived from
    gdb.base/flexible-array-member.exp.  It tests the same things, but
    through the Python API.  It also specifically tests getting the range
    from the various kinds of flexible array member types (AFAIK it wasn't
    possible to do the equivalent through the CLI).
    
    gdb/ChangeLog:
    
            PR gdb/27757
            * python/py-type.c (typy_range): Check that bounds are constant
            before accessing them as such.
            * guile/scm-type.c (gdbscm_type_range): Likewise.
    
    gdb/testsuite/ChangeLog:
    
            PR gdb/27757
            * gdb.python/flexible-array-member.c: New test.
            * gdb.python/flexible-array-member.exp: New test.
            * gdb.guile/scm-type.exp (test_range): Add test for flexible
            array member.
            * gdb.guile/scm-type.c (struct flex_member): New.
            (main): Use it.
    
    Change-Id: Ibef92ee5fd871ecb7c791db2a788f203dff2b841

The gdb-10-branch branch has been updated by Simon Marchi <simark@sourceware.org>:

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

commit a2602365509739da6f611d1668eebdb8ea1bffec
Author: Simon Marchi <simon.marchi@polymtl.ca>
Date:   Thu Apr 22 15:05:18 2021 -0400

    gdb: fix getting range of flexible array member in Python
    
    As reported in bug 27757, we get an internal error when doing:
    
        $ cat test.c
        struct foo {
            int len;
            int items[];
        };
    
        struct foo *p;
    
        int main() {
            return 0;
        }
        $ gcc test.c -g -O0 -o test
        $ ./gdb -q -nx --data-directory=data-directory ./test -ex 'python gdb.parse_and_eval("p").type.target()["items"].type.range()'
        Reading symbols from ./test...
        /home/simark/src/binutils-gdb/gdb/gdbtypes.h:435: internal-error: LONGEST dynamic_prop::const_val() const: Assertion `m_kind == PROP_CONST' failed.
        A problem internal to GDB has been detected,
        further debugging may prove unreliable.
        Quit this debugging session? (y or n)
    
    This is because the Python code (typy_range) blindly reads the high
    bound of the type of `items` as a constant value.  Since it is a
    flexible array member, it has no high bound, the property is undefined.
    Since commit 8c2e4e0689 ("gdb: add accessors to struct dynamic_prop"),
    the getters check that you are not getting a property value of the wrong
    kind, so this causes a failed assertion.
    
    Fix it by checking if the property is indeed a constant value before
    accessing it as such.  Otherwise, use 0.  This restores the previous GDB
    behavior: because the structure was zero-initialized, this is what was
    returned before.  But now this behavior is explicit and not accidental.
    
    Add a test, gdb.python/flexible-array-member.exp, that is derived from
    gdb.base/flexible-array-member.exp.  It tests the same things, but
    through the Python API.  It also specifically tests getting the range
    from the various kinds of flexible array member types (AFAIK it wasn't
    possible to do the equivalent through the CLI).
    
    gdb/ChangeLog:
    
            PR gdb/27757
            * python/py-type.c (typy_range): Check that bounds are constant
            before accessing them as such.
            * guile/scm-type.c (gdbscm_type_range): Likewise.
    
    gdb/testsuite/ChangeLog:
    
            PR gdb/27757
            * gdb.python/flexible-array-member.c: New test.
            * gdb.python/flexible-array-member.exp: New test.
            * gdb.guile/scm-type.exp (test_range): Add test for flexible
            array member.
            * gdb.guile/scm-type.c (struct flex_member): New.
            (main): Use it.
    
    Change-Id: Ibef92ee5fd871ecb7c791db2a788f203dff2b841

Marking as fixed, but if you could give it a try to make sure your use case now works well, it would be appreciated.

That was fast:)
Thanks, we'll try to test

See bug #27770 for the interpreter-exec crasher.