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

["elias.myllymaki04p at gmail dot com" <sourceware-bugzilla@sourceware.org>]

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.