[Bug gdb/30032] New: GDB claims that _sifields does not exist even though it does.

[Bug gdb/30032] New: GDB claims that _sifields does not exist even though it does.

[elias.myllymaki04p at gmail dot com]

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

            Bug ID: 30032
           Summary: GDB claims that _sifields does not exist even though
                    it does.
           Product: gdb
           Version: 9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: elias.myllymaki04p at gmail dot com
  Target Milestone: ---

Hi!

I have made a map parsing program which takes a certain file format which
encodes a video game map and tries to parse said file. The files are too large
to be uploaded here so I uploaded them to this google drive zip file:
https://drive.google.com/file/d/1jxMAsK_hdtORP4e4OxqyelU1Dd5-ENm7/view?usp=sharing


Decompress that file into an empty directory then do these commands in the
reproduction directory:

export LD_LIBRARY_PATH=$PWD/bin/linux64/
gdb ./bspfuzz

and then inside gdb run this command:

r test.bsp master01.bsp 27015 < crash.bsp


it should then crash.

Then after the crash when I type this command:

p $_siginfo._sifields._sigfault.si_addr

it claims that "There is no member named _sifields."

However if I type this command:

p $_siginfo._sifields._sigfault

it gives me this output:

$1 = {si_addr = 0x0, _addr_lsb = 0, _addr_bnd = {_lower = 0x0, _upper = 0x0}}

which clearly shows si_addr as an element inside it.

I do not know if this is a bug or intended behaviour, but decided to report
this just in case.


gdb --version : 

GNU gdb (Ubuntu 9.2-0ubuntu1~20.04.1) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law



The source code for the program is basically in
https://github.com/SwagSoftware/Kisak-Strike . I implemented a wrapper around
the GetModelForName function which tries to load the crash.bsp file. One
notable difference is that I compiled this version of the bspfuzz binary with
afl-gcc to use the afl fuzzer with it. Now I want to make it clear that the
issue which I am claiming to be an issue is not the crash itself, but the
_siginfo command behaviour. Can someone tell me if this is intended behaviour
or a bug?

Thanks in advance for the help? 

Of course feel free to ask for clarification on anything.

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

[Bug gdb/30032] GDB claims that _sifields does not exist even though it does.

[elias.myllymaki04p at gmail dot com]

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

Elias Myllymäki <elias.myllymaki04p at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |elias.myllymaki04p at gmail dot co
                   |                            |m

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

[Bug gdb/30032] GDB claims that _sifields does not exist even though it does.

[ssbssa at sourceware dot org]

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

Hannes Domani <ssbssa at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ssbssa at sourceware dot org

--- Comment #1 from Hannes Domani <ssbssa at sourceware dot org> ---
Did you build with macro informations -g3?
I expect that `info macro si_addr` will output `#define si_addr
_sifields._sigfault.si_addr`.

And in that case you can just do `p $_siginfo.si_addr`.

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

[Bug gdb/30032] GDB claims that _sifields does not exist even though it does.

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2023-01-30
     Ever confirmed|0                           |1

--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
OP, can you try that suggestion?
Thanks.

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

[Bug gdb/30032] GDB claims that _sifields does not exist even though it does.

[elias.myllymaki04p at gmail dot com]

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

--- Comment #3 from Elias Myllymäki <elias.myllymaki04p at gmail dot com> ---
Ok yeah p $_siginfo.si_addr does sometimes work, but sometimes it does not work
and I have to use p $_sifields._sigfault.si_addr. I forgot where I put the
testcase which reproduces this. I don't know if that is expected behaviour or
not.

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