[Bug mi/29426] New: FAIL: gdb.mi/mi-var-invalidate.exp: linteger not anymore in scope due to binary changes (unexpected output)

[Bug mi/29426] New: FAIL: gdb.mi/mi-var-invalidate.exp: linteger not anymore in scope due to binary changes (unexpected output)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29426

            Bug ID: 29426
           Summary: FAIL: gdb.mi/mi-var-invalidate.exp: linteger not
                    anymore in scope due to binary changes (unexpected
                    output)
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: mi
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

I'm running into:
...
FAIL: gdb.mi/mi-var-invalidate.exp: linteger not anymore in scope due to binary
changes (unexpected output)
FAIL: gdb.mi/mi-var-invalidate.exp: no type for invalid variable linteger (1)
(unexpected output)
...

In more detail:
...
PASS: gdb.mi/mi-var-invalidate.exp: set format variable float_simple
Expecting: ^(-var-update linteger[^M
]+)?(\^done,changelist=\[{name="linteger",in_scope="invalid",has_more="0"}\][^M
]+[(]gdb[)] ^M
[ ]*)
-var-update linteger^M
^done,changelist=[{name="linteger",in_scope="false",type_changed="false",has_more="0"}]^M
(gdb) ^M
FAIL: gdb.mi/mi-var-invalidate.exp: linteger not anymore in scope due to binary
changes (unexpected output)
...

Also I'm seeing these, and assuming they're related:
...
FAIL: gdb.mi/mi-var-invalidate-shlib.exp: separate_debuginfo=0: in new process:
global_var recreated (unexpected output)
FAIL: gdb.mi/mi-var-invalidate-shlib.exp: separate_debuginfo=1: in new process:
global_var recreated (unexpected output)
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug mi/29426] FAIL: gdb.mi/mi-var-invalidate.exp: linteger not anymore in scope due to binary changes (unexpected output)

[lsix at lancelotsix dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=29426

Lancelot SIX <lsix at lancelotsix dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lsix at lancelotsix dot com

--- Comment #1 from Lancelot SIX <lsix at lancelotsix dot com> ---
I could not see those issues on ubuntu-20.04 (gcc-9.4.0) nor ubuntu-22.04
(gcc-11.2.0).

I finally managed to reproduce it on opensuse/tumbleweed which uses gcc-12.1.1.

Turns out that if I compile the testcase with HEAD gcc (13.0.0) on ubuntu, I
can reproduce the issue:

```
$ $HOME/opt/gcc/bin/gcc --version
gcc (GCC) 13.0.0 20220729 (experimental)
Copyright © 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

# make check-gdb \
    TESTS="gdb.mi/mi-var-invalidate-shlib.exp gdb.mi/mi-var-invalidate.exp" \
    RUNTESTFLAGS=CC_FOR_TARGET=$HOME/opt/gcc/bin/gcc
[...]
Running
/home/lsix/dev/binutils-gdb/_build/gdb/testsuite/../../../gdb/testsuite/gdb.mi/mi-var-invalidate-shlib.exp
...
FAIL: gdb.mi/mi-var-invalidate-shlib.exp: separate_debuginfo=0: in new process:
global_var recreated (unexpected output)
FAIL: gdb.mi/mi-var-invalidate-shlib.exp: separate_debuginfo=1: in new process:
global_var recreated (unexpected output)
Running
/home/lsix/dev/binutils-gdb/_build/gdb/testsuite/../../../gdb/testsuite/gdb.mi/mi-var-invalidate.exp
...
FAIL: gdb.mi/mi-var-invalidate.exp: linteger not anymore in scope due to binary
changes (unexpected output)
FAIL: gdb.mi/mi-var-invalidate.exp: no type for invalid variable linteger (1)
(unexpected output)

                === gdb Summary ===

# of expected passes            56
# of unexpected failures        4
```

I’ll investigate further to see what changed in the compiler’s output.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug mi/29426] FAIL: gdb.mi/mi-var-invalidate.exp: linteger not anymore in scope due to binary changes (unexpected output)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29426

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Lancelot SIX from comment #1)
> I could not see those issues on ubuntu-20.04 (gcc-9.4.0) nor ubuntu-22.04
> (gcc-11.2.0).
> 
> I finally managed to reproduce it on opensuse/tumbleweed which uses
> gcc-12.1.1.
> 
> Turns out that if I compile the testcase with HEAD gcc (13.0.0) on ubuntu, I
> can reproduce the issue:
> 

FWIW, I'm ran into it on openSUSE Leap 15.3, using gcc 7.5.0.

Also reproduces for me with gcc 8.2.1, 9.3.1, 10.3.0, 11.2.1, and 12.1.1 as
well as with clang 8.0.1 and 13.0.0.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug mi/29426] FAIL: gdb.mi/mi-var-invalidate.exp: linteger not anymore in scope due to binary changes (unexpected output)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29426

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
I've bisected the fails in gdb.mi/mi-var-invalidate.exp to commit bc20e562ec0
("gdb/varobj: Fix use after free in varobj").

Note btw that that commit doesn't touch that test-case:
...
$ git show bc20e562ec0436b6117b989c0e3d8f66c9d4d979 | grep diff
diff --git a/gdb/testsuite/gdb.mi/mi-var-invalidate-shlib-lib.c
b/gdb/testsuite/gdb.mi/mi-var-invalidate-shlib-lib.c
diff --git a/gdb/testsuite/gdb.mi/mi-var-invalidate-shlib.c
b/gdb/testsuite/gdb.mi/mi-var-invalidate-shlib.c
diff --git a/gdb/testsuite/gdb.mi/mi-var-invalidate-shlib.exp
b/gdb/testsuite/gdb.mi/mi-var-invalidate-shlib.exp
diff --git a/gdb/value.c b/gdb/value.c
diff --git a/gdb/varobj.c b/gdb/varobj.c
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug mi/29426] FAIL: gdb.mi/mi-var-invalidate.exp: linteger not anymore in scope due to binary changes (unexpected output)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29426

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
Hmm, maybe this is the root cause:
...
$ file outputs/gdb.mi/mi-var-invalidate/mi-var-invalidate
outputs/gdb.mi/mi-var-invalidate/mi-var-invalidate: ELF 64-bit LSB executable,
x86-64, version 1 (SYSV), dynamically linked, interpreter
/lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=78504e3e944b94c9646d9434157eb089b28570ea, for GNU/Linux 3.2.0,
with debug_info, not stripped
$ file outputs/gdb.mi/mi-var-invalidate/mi-var-invalidate_bis 
outputs/gdb.mi/mi-var-invalidate/mi-var-invalidate_bis: ELF 64-bit LSB
executable, x86-64, version 1 (SYSV), dynamically linked, interpreter
/lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=78504e3e944b94c9646d9434157eb089b28570ea, for GNU/Linux 3.2.0,
with debug_info, not stripped
...

Identical BuildID between mi-var-invalidate and mi-var-invalidate_bis.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug mi/29426] FAIL: gdb.mi/mi-var-invalidate.exp: linteger not anymore in scope due to binary changes (unexpected output)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29426

--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
I observe the following sequence of events:
- varobj_create creates var and sets var.root.valid_block to non-null
- varobj_invalidate_if_uses_objfile
  sets valid_block to null
- varobj_invalidate_iter inspects var.root.valid_block, sees it's null,
  and decided that it's a global variable and tries to recreate it, which
  succeeds.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug mi/29426] FAIL: gdb.mi/mi-var-invalidate.exp: linteger not anymore in scope due to binary changes (unexpected output)

[lsix at lancelotsix dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=29426

--- Comment #6 from Lancelot SIX <lsix at lancelotsix dot com> ---
Hi

This is what I also see.  TBH, I am really wondering why I have not seen with
my testing and with my ubuntu boxes.

I am working on a fix for this.

Thanks for taking the time and looking into it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug mi/29426] FAIL: gdb.mi/mi-var-invalidate.exp: linteger not anymore in scope due to binary changes (unexpected output)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29426

--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Lancelot SIX from comment #6)
> Hi
> 
> This is what I also see.  TBH, I am really wondering why I have not seen
> with my testing and with my ubuntu boxes.
> 

It's PIE vs. no-PIE (and not for the first time ;) ).

So my system has no-PIE by default (because I haven't installed the gcc-PIE
package).

Using target board unix/-fPIE/-pie (case PIE), the test passes.  Using unix
(case no-PIE), it fails.

On ubuntu, there's a PIE default for system gcc.  When you build gcc from
scratch, it probably had no-PIE default instead.

Anyway, in one case (no-PIE) var_create succeeds, in the other (PIE) not.

So, varobj_create calls get_frame_block, which calls block_for_pc, with a
relocated pc.  Then block_for_pc calls block_for_pc_sect, which call
blockvector_for_pc_sect, which calls find_pc_sect_compunit_symtab, which calls
objf->find_pc_sect_compunit_symtab with objf == mi-var-invalidate_bis.

In the PIE case, this query returns null because we try to find an relocated
address in an unrelocated objfile.

In the no-PIE case, this query returns non-null because we try to find an
non-relocatable address in an non-relocatable objfile.


In the PIE case

> I am working on a fix for this.
> 
> Thanks for taking the time and looking into it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug mi/29426] FAIL: gdb.mi/mi-var-invalidate.exp: linteger not anymore in scope due to binary changes (unexpected output)

[lsix at lancelotsix dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=29426

--- Comment #8 from Lancelot SIX <lsix at lancelotsix dot com> ---
Created attachment 14242
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14242&action=edit
add_varobj_global_flag.patch

This regression also shows an interesting problem.

Currently, when we unload an objfile and find a varobj which is linked to a
block from this objfile, we clear the valid_block pointer to avoid having a
stall pointer.  However by doing this, we loose the ability to distinguish a
varobj tracking a global (no valid_block associated) to a varobj tracking a
local (some valid_block associated).  Later, when we reload a new program and
try to recreate varobj for globals, we have false positive and also try to
recreate some locals as well.

The attached patch fixes this, but some differences remain whether I ubuntu’s
stock GCC or custom built HEAD GCC.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug mi/29426] FAIL: gdb.mi/mi-var-invalidate.exp: linteger not anymore in scope due to binary changes (unexpected output)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29426

--- Comment #9 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Lancelot SIX from comment #8)
> Created attachment 14242 [details]
> add_varobj_global_flag.patch
> 
> This regression also shows an interesting problem.
> 
> Currently, when we unload an objfile and find a varobj which is linked to a
> block from this objfile, we clear the valid_block pointer to avoid having a
> stall pointer.  However by doing this, we loose the ability to distinguish a
> varobj tracking a global (no valid_block associated) to a varobj tracking a
> local (some valid_block associated).  Later, when we reload a new program
> and try to recreate varobj for globals, we have false positive and also try
> to recreate some locals as well.
> 
> The attached patch fixes this, but some differences remain whether I
> ubuntu’s stock GCC or custom built HEAD GCC.

Ack, this fixes the gdb.mi/mi-var-invalidate.exp regression for me.

But I still see:
...
$ grep ^FAIL: gdb.sum 
FAIL: gdb.mi/mi-var-invalidate-shlib.exp: separate_debuginfo=0: in new process:
global_var recreated (unexpected output)
FAIL: gdb.mi/mi-var-invalidate-shlib.exp: separate_debuginfo=1: in new process:
global_var recreated (unexpected output)
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug mi/29426] FAIL: gdb.mi/mi-var-invalidate.exp: linteger not anymore in scope due to binary changes (unexpected output)

[lsix at lancelotsix dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=29426

Lancelot SIX <lsix at lancelotsix dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #10 from Lancelot SIX <lsix at lancelotsix dot com> ---
Fixes for this issue have landed in master (various patches up to
906dca17d429f468d49a6cc4753993581c51a899).

I think this can now be closed, but please re-open if problems persist.

-- 
You are receiving this mail because:
You are on the CC list for the bug.