Referencing libSupportHTTP under LINK_LIBS of add_lldb_library() pulls
in the static archive even in a build configuration with
LLVM_LINK_LLVM_DYLIB=On, where libSupportHTTP is part of libLLVM. This
patch moves it to LINK_COMPONENTS to fix the issue.
This is the same fix as in
036429881f8d3037894042c6268b2a94eac8c950, applied on another
library.
When targeting arm64e, ISA pointers, class_ro_t pointers, and interface
selectors are signed in Objective-C. This PR adds support for that in
the expression evaluator.
Depends on:
* https://github.com/llvm/llvm-project/pull/187229
(only second commit and onwards are relevant)
This patch implements the base infrastructure described in this [RFC re.
Moving libc++ data-formatters out of
LLDB](https://discourse.llvm.org/t/rfc-lldb-moving-libc-data-formatters-out-of-lldb/89591)
The intention is to provide vendors with a way to pre-configure a set of
paths that LLDB can automatically ingest formatter scripts from.
Three main changes:
1. Adds a CMake variable `LLDB_SAFE_AUTO_LOAD_PATHS` which is a
semi-colon separated list of paths. This is intended to be set by
vendors when building LLDB for distribution.
2. Adds a setting that only exists in asserts mode called
`testing.safe-auto-load-paths` which allows setting the paths without a
CMake configuration. Used for local development and, more crucially, the
shell and unit tests
3. Adds a `LocateScriptingResourcesFromSafePaths` which
`Platform::LocateExecutableScriptingResources` calls by default (and
hence used by all platforms). I add a
`LocateExecutableScriptingResourcesImpl` that platforms can override if
they have platform-specific resource script locations (e.g., dSYMs on
Darwin).
Whenever we load an image, we check the safe path (starting with the
last appended path) for a directory called
`/safe/path/to/<module>/<module>.py`. If such script exists, we import
it as a Python module. If not, we move on to the next safe path.
Currently the default for `LLDB_SAFE_AUTO_LOAD_PATHS` is empty.
Eventually the plan is to make those point to the libc++ installation
(where the formatters will live) depending on platform/vendor. For macOS
we'll add a special `$SDK_ROOT` that can be used in the path variable,
which `LocateScriptingResourcesFromSafePaths` will resolve to an actual
SDK path.
*AI Usage*:
* Claude assisted with the CMake machinery which I then reviewed and
cleaned up. I'm not sure this is the most idiomatic way of letting a
user provide lists of paths, but I couldn't find a better way.
* Wrote the basic auto-load Shell tests myself and asked claude to stamp
out a bunch more for different scenarios. Reviewed and cleaned those up
myself.
When targeting arm64e, we enable `-fptrauth-indirect-gotos` by default,
which signs label addresses and authenticates indirect branches. Add
support (and a test) for this in the LLDB expression evaluator.
This changes the inputs to `update`. It's now the data stack that was
the result of `@init`. This makes `update` more predictable, as its
inputs are the same between the first call and the Nth call.
The initial version of SymbolLocatorSymStore supported servers only on
local paths. This patch extends it to HTTP/HTTPS end-points. For that to
work on Windows, we add a WinHTTP-based HTTP client backend in LLVM next
to the existing CURL-based implementation.
We don't add a HTTP server implementation, because there is no use right
now. Test coverage for the LLVM part is built on llvm-debuginfod-find
and works server-less, since it checks textual output of request
headers. The existing CURL-based implementation uses the same approach.
The LLDB API test for the specific SymbolLocatorSymStore feature spawns
a HTTP server from Python.
To keep the size of this patch within reasonable limits, the initial
implementation of the SymbolLocatorSymStore feature is dump: There is no
caching, no verification of downloaded files and no protection against
file corruptions. We use a local implementation of LLVM's
HTTPResponseHandler, but should think about extracting and reusing
Debuginfod's StreamedHTTPResponseHandler in the future.
The goal of this patch is a basic working implementation that is
testable in isolation. We will iterate on it to improve it further. This
should be fine since downloading from SymStores is not default-enabled
yet. Users have to set their server URLs explicitly.
---------
Co-authored-by: Alexandre Ganea <aganea@havenstudios.com>
**Description:**
Adds `IsMemberDataPointerType()` to CompilerType / TypeSystem /
TypeSystemClang, mirroring the existing `IsMemberFunctionPointerType()`.
LLDB already has `IsMemberFunctionPointerType()` to identify member
function pointers but no counterpart for member data pointers. The only
way to check for member data pointers was the indirect `GetTypeClass()
== eTypeClassMemberPointer && !IsMemberFunctionPointerType()`, which is
awkward.
This pr is split out from a larger [fix,
186629](https://github.com/llvm/llvm-project/pull/186629) for LLDB
mishandling non-type template parameters (NTTPs) of pointer-to-member
types, where cleanly distinguishing member data pointers from member
function pointers is needed. The new API delegates to clang's
`QualType::isMemberDataPointerType()` via the same I`sTypeImpl` pattern
used by `IsMemberFunctionPointerType`.
**Test Plan:**
Added `TestIsMemberDataPointerType` to `TestTypeSystemClang.cpp` that
verifies:
`int S::*` → `IsMemberDataPointerType() = true`,
`IsMemberFunctionPointerType() = false`
`void (S::*)()` → `IsMemberDataPointerType() = false`,
`IsMemberFunctionPointerType() = true`
`int * (regular pointer)` → both false
`int (non-pointer)`→ both false
This PR upstreams support for PtrAuth in the LLDB expression evaluator.
It's a rebased version of an older patch in the Swiftlang repo
(https://github.com/swiftlang/llvm-project/pull/5012) but adapted to not
rely on `GlobalPtrAuthInfo.h`. I followed Anton's advice, and instead of
iterating over all globals and hack on wrappers, the pass now iterates
over all global uses and fixes up ConstantPtrAuth expressions if any.
This is one of the last large chunks of downstream PtrAuth code in LLDB,
and the primary blocker for running the LLDB test suite in arm64e mode
on Apple Silicon, which I'd really like to make the default in the
future.
Fetch the size of the shared cache address range in VM in the inferior
process and return it, if possible. This allows for a simple call to
DynamicLoader::GetSharedCacheInformation to get the virtual address
extent of the shared cache in the inferior. It's a minor addition to the
method that fetches the shared cache filepath from the inferior, plus
piping it up through lldb's layers.
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
This is a follow-up to
https://github.com/swiftlang/llvm-project/pull/12317#discussion_r2850297229
Per that discussion, given that deserializers *can* fail given a corrupt
PDB, it's preferable to handle the error instead of crashing.
This specific change is limited to "easy" changes (read: I have high
confidence in their correctness). The ideal end state is funneling all
errors to a few central places in `SymbolFileNativePDB`.
In preparation for https://github.com/llvm/llvm-project/pull/187031
The `SanitizedScriptingModuleName` will be re-used from `Platform` (in
addition to `PlatformDarwin` where it currently lives). To do that we'll
need to move it to a common place. `ScriptInterpreter` seems like the
most natural place for this to live.
I introduced a new virtual `GetSanitizedScriptingModuleName` that
`ScriptInterpreter`s can override in the future if they have their own
sanitization logic. I made the default implementation the one we've been
using for Python because that way the unit-tests that currently mock the
`ScriptInterpreter` don't need to copy the implementation.
Also made `WarnIfInvalidUnsanitizedScriptExists` a protected static
function on `Platform` because it didn't seem right for that to also
live in `ScriptInterpreter`.
lldb had three preprocessor defines for logging,
LLDB_LOG - formatv style argument
LLDB_LOGF - printf style argument
LLDB_LOGV - formatv style argument, only when verbose enabled
If you weren't looking at Log.h and the definition of these three, and
wanted to log something with formatv, it was easy to use LLDB_LOGV by
accident. We just had a situation where an important log statement
wasn't logging and it turned out to be this. This is fragile if you
aren't looking at the header directly, so I'd like to make this more
explicit. My proposal:
LLDB_LOG - formatv style argument
LLDB_LOG_VERBOSE - formatv style argument, only when verbose enabled
LLDB_LOGF - printf style argument
LLDB_LOGF_VERBOSE - printf style argument, only when verbose enabled
The new fouth one is to remove several places where we do `if (log &&
log->GetVerbose()) LLDB_LOGF (...)` in the sources today, and make both
styles consistent.
This PR implements that change, mechanically changing all LLDB_LOGV's to
LLDB_LOG_VERBOSE.
It also updates many of the `if (log && log->GetVerbose()) LLDB_LOGF`'s.
Some uses of this conditional expression do extra calculations in
addition to logging, and so those were left as-is so we're not doing
throwaway work when running without verbose logging.
There were many instances throughout lldb where callers are still doing
`if (log) LLDB_LOG*(...)`, a remnant of when all calls were to the `Log`
object's `Printf()` method, and you had to check if your local Log*
pointer was non-nullptr before calling the method. I removed those,
again keeping ones where work for logging is done in the block of code.
The code changes are all mechanical and uninteresting, but the question
of whether this naming change is widely agreed on is maybe worth
discussing.
Fix and improve #187145 for following issues:
* Fix unhandled error.
* Align the log type with the file where it contains.
* The added test doesn't work on windows host for remote debugging, add
decorator to skip when host and target do not match.
The messages about searching for call edges can be really verbose and
they are only useful if you are explicitly debugging the call edges
feature. Most of the time they are irrelevant and just make the step log
output hard to read.
Add a LoadCompilationPrefixMap() helper in SymbolFile::FindPlugin that
walks up from the symbol file's directory looking for a
compilation-prefix-map.json file. When found, each key→value entry is
applied to the module's source path mapping list, allowing LLDB to
resolve source file paths that were rewritten by -fdebug-prefix-map at
build time without requiring manual `settings set target.source-map`.
The JSON file format maps fake paths (as written into debug info) back
to their real on-disk counterparts:
{ "/fake/srcdir": "/real/srcdir" }
Directory results are cached so the filesystem is walked at most once
per unique directory across all modules loaded in a session.
Also apply the module's source path remappings in
SymbolFileDWARFDebugMap::ParseCompileUnitAtIndex when constructing
compile units from N_SO stabs. This mirrors what MakeAbsoluteAndRemap
does for the dSYM case so that fake paths baked into the debug map are
transparently resolved to real paths.
rdar://84824567
Assisted-By: Claude
I'm in the process of moving `SanitizedScriptingModuleName` into
`ScriptInterpreter` as a `virtual` API. The nullptr check inside the
constructor made that more difficult because it implied we may not have
a `ScriptInterpreter` available to call the sanitization API on. Really
the `nullptr` check is redundant because even if we succesfully sanitize
and then locate some scripts, `Module::LoadScriptingResourceInTarget`
bails out if we don't have a `ScriptInterpreter`.
This patch moves the early exit in `LoadScriptingResourceInTarget` to
before we make the call to `LocateExecutableScriptingResources`. That
way we ensure we never get to `SanitizedScriptingModuleName` without a
valid `ScriptInterpreter`.
In #186001, I said the last large chunk of downstream PtrAuth code in
LLDB was the expression evaluator support. However, that wasn't
accurate, as we also have changes to thread this through ValueObject.
The variable `matches` may be assigned the address of block-scope
`local_matches`, which is defined in a scope strictly smaller than the
scope of `matches`. Towards the end of the function, after
`loacl_matches` has been destroyed, `matches` is accessed, possibly
triggering a user-after-free.
This patch makes the warning message more concise (in my opinion). We
would duplicate the file path multiple times in the message. I'm
planning on factoring this logic into a standalone function, and having
it rely on fewer parameters helps with that.
Before:
```
warning: the symbol file '/path/to/.dSYM/Contents/Resources/DWARF/import' contains a debug script.
However, its name '/path/to/.dSYM/Contents/Resources/DWARF/../Python/import.py' conflicts with a keyword
and as such cannot be loaded. LLDB will load '/path/to/.dSYM/Contents/Resources/DWARF/../Python/_import.py' instead.
Consider removing the file with the malformed name to eliminate this warning.
```
After:
```
warning: debug script '/path/to/.dSYM/Contents/Resources/DWARF/../Python/import.py' cannot be loaded
because 'import.py' conflicts with the keyword 'import'. Ignoring 'import.py' and loading '_import.py' instead.
```
Before:
```
warning: the symbol file '/path/to/.dSYM/Contents/Resources/DWARF/import' contains a debug script.
However, its name conflicts with a keyword and as such cannot be loaded.
If you intend to have this script loaded, please rename '/path/to/.dSYM/Contents/Resources/DWARF/../Python/import.py'
to '/path/to/.dSYM/Contents/Resources/DWARF/../Python/_import.py' and retry.
```
After:
```
warning: debug script '/path/to/.dSYM/Contents/Resources/DWARF/../Python/import.py' cannot be loaded
because 'import.py' conflicts with the keyword 'import'. If you intend to have this script loaded, please rename
it to '_import.py' and retry.
```
Minimal infrastructure for a the SymbolLocator plugin that fetches debug
info from Microsoft SymStore repositories. This can work cross-platform
and for various debug info formats in principle, but the current plan is
focussed on PE/COFF on Windows with debug info in PDB files. Once we
have a stable first version, we'd like to add features like download,
environment variables, caching and progress feedback for users.
SymbolVendorPECOFF was tailored towards DWARF debug info so far. I added
code to load the PDB path from the executable (it only checked
gnu_debuglink so far) and not bail out if DWARF sections are missing, so
that in the PDB case we still call AddSymbolFileRepresentation() in the
very end of CreateInstance().
The API test in this patch mocks the directory layout from SymStore, so
it doesn't depend on SymStore.exe from the Windows SDK. It runs on all
platforms that link debug info in a PDB file, which is still just
Windows, but it could be cross-platform in principle.
-----
Relands with minor fixes: API tests create mocked SymStore in the test's
build directory. One log instruction was moved. One more object
access goes through module in SymbolFile.
I'm in the process of making `LoadScriptingResources` interactively ask
a user whether to load a script. I'd like to turn the existing warning
into the prompt. The simplest way to achieve this is to not print into a
`feedback_stream` parameter, and instead create a prompt right there.
This patch removes the `feedback_stream` parameter and emits a
`ReportWarning` instead. If we get around to adding the prompt instead
of the warning, those changes will be simpler to review. But even if we
don't end up replacing the warning with a prompt, moving away from
output parameters and towards more structured error reporting is a
nice-to-have (e.g., the `warning` prefix is now colored, IDEs have more
flexibility on how to present the warning, etc.).
For a command-line user nothing should change with this patch (apart
from `warning:` being highlighted).
Referencing libSupportHTTP under LINK_LIBS of add_lldb_library() pulls
in the archive even in a build configuration with
LLVM_LINK_LLVM_DYLIB=On, where libSupportHTTP is part of libLLVM. This
patch moves it to LINK_COMPONENTS to fix the issue.
[lldb] Preserve TargetSP in Platform module lookup
When `Platform::GetRemoteSharedModule` resolves a module specification
by calling `GetModuleSpec` on
the process, the target context (`TargetSP`) is lost. This happens
because the underlying process plugin populates a new `ModuleSpec`
object that does not inherit the target context.
This causes failures in subsequent symbol resolution steps. For example,
when `ModuleList` relies on the `TargetSP` to query target-specific
settings like `target.exec-search-paths` and
`target.symbols-search-paths`, the lookup fails
because `TargetSP` evaluates to null. This prevents LLDB from finding
local unstripped libraries.
This commit fixes the issue by transferring the target context from the
original `module_spec` over to the `resolved_module_spec` before
proceeding with the lookup.
Additionally, this commit avoids redundant calls to the locate module
callback. Since the platform already handles the callback explicitly,
passing the target context to subsequent `ModuleList::GetSharedModule`
calls would normally trigger the callback again redundantly. This is
suppressed by passing `invoke_locate_callback=false` in
`Platform::GetSharedModule` and `ModuleCache::Get`. This also avoids
triggering the callback with incomplete module specifications (e.g.
cleared UUIDs) during cache lookups.
In #183172, I added support for reading `S_REGREL32_INDIR` records. This
adds support in LLDB. The record is emitted by MSVC for structured
bindings and in the compiler generated coroutine stubs.
It describes a location at `*(Register + Offset) + OffsetInUdt`.
Equivalent to
```
DW_OP_breg{reg} {Offset}
DW_OP_deref
DW_OP_plus_uconst {OffsetInUdt}
```
LLVM doesn't create this record - it only creates `S_LOCAL`s for local
variables. We'll probably need `S_DEFRANGE_REGISTER_REL_INDIR` for this
- should be simple to figure out the structure, but I haven't seen that
record emitted yet.
Use `kvm_kerndisp()` on core load to retrieve the kernel displacement,
that is the difference between the kernel's
base virtual address at run time and the kernel base virtual address
specified in the kernel image file. Currently PowerPC is the only
architecture supporting kernel displacement.
---------
Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
This patch extracts the `msg` value of the `failwithmessage` error and
uses it as the stop reason if the MSVC Runtime fails while debugging.
# Before
```
lldb.exe C:\Users\charleszablit\Developer\testing\uninit.exe -b -o 'r'
(lldb) target create "C:\\Users\\charleszablit\\Developer\\testing\\uninit.exe"
Current executable set to 'C:\Users\charleszablit\Developer\testing\uninit.exe' (x86_64).
(lldb) r
Process 9400 launched: 'C:\Users\charleszablit\Developer\testing\uninit.exe' (x86_64)
Process 9400 stopped
* thread #1, stop reason = Exception 0x80000003 encountered at address 0x7ff96516c96a
frame #0: 0x00007ff77efe20ba uninit.exe`failwithmessage(retaddr=0x00007ff77efe150f, crttype=1, errnum=3, msg="The variable 'x' is being used without being initialized.") at error.cpp:210
```
# After
```
lldb.exe C:\Users\charleszablit\Developer\testing\uninit.exe -b -o 'r'
(lldb) target create "C:\\Users\\charleszablit\\Developer\\testing\\uninit.exe"
Current executable set to 'C:\Users\charleszablit\Developer\testing\uninit.exe' (x86_64).
(lldb) r
Process 9400 launched: 'C:\Users\charleszablit\Developer\testing\uninit.exe' (x86_64)
Process 9400 stopped
* thread #1, stop reason = Run-time check failure: The variable 'x' is being used without being initialized.
frame #0: 0x00007ff77efe20ba uninit.exe`failwithmessage(retaddr=0x00007ff77efe150f, crttype=1, errnum=3, msg="The variable 'x' is being used without being initialized.") at error.cpp:210
```
fix https://github.com/llvm/llvm-project/issues/184990.
rdar://172103284
Makes it obvious what the warning will look like (with the indenentation
etc.). Also adds a test since we had no coverage for the warning before
(as far as I'm aware).
The `ScriptInterpreterPython` will refuse to load script names that
contain `+`. This patch makes `SanitizedScriptingModuleName` handle this
by replacing it with `x`. That might seem a bit arbitrary but the way
the current dSYM script loading (and the future "auto-load") mechanism
works is that it will look for scripts called `<lldb-module-name>.py`.
So for something like `libc++.1.dylib`, we would look for `libc++.1.py`.
Replacing `x` with `_` like we do for other special characters would
look strange in my opinion. The simplest way of working around this is
to recommend renaming the script to `libcxx_1.py`.
An alternative to the whole "replace special characters" logic is to
have a MANIFEST file which advertises the script name that LLDB should
load. During reading that script we could bail if we saw special
characters. But I haven't thought that through fully. And since the
`llvm::replace` approach is the path of least resistence I went with it
for now.
Planning on adding more to this function/loop soon. Making it
early-return style (as suggested by the LLVM style guide) makes those
changes easier to reason about.
Drive-by:
* Reduced the indentation of the loop by doing an early-continue if the
`FileSpec` is invalid or doesn't exist
Fixes a redefinition warning on Ubuntu 25.10 coming from `ptrace.h`
including `hwcap.h`.
```
/home/jonas/llvm/llvm-project/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp:84:9: warning: ‘HWCAP2_POE’ redefined
84 | #define HWCAP2_POE (1ULL << 63)
| ^~~~~~~~~~
In file included from /usr/include/aarch64-linux-gnu/asm/ptrace.h:25,
from /home/jonas/llvm/llvm-project/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h:19,
from /home/jonas/llvm/llvm-project/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp:11:
/usr/include/aarch64-linux-gnu/asm/hwcap.h:141:9: note: this is the location of the previous definition
141 | #define kkk (1UL << 63)
| ^~~~~~~~~~
```
Currently these functions take a target pointer. In Cross-language
projects this means it's down to chance what typesystem the resulting
value will be in, since the implementation returns the first scratch
type system in the target, which depends on the order of images and
their implementation language.
By passing in an execution context the selected frame is used to
determine the typesystem, which is usually the expected outcome when
using DIL.
This should be entirely NFC for Clang-only LLDBs, but is a necessity for
LLDBs with additional type system plugins such as the Swift plugin.
Assisted by Claude to patch the call sites.
Use the same format string in DWARFCompileUnit.cpp as we do everywhere
else to report the error from GetAttributeAddressRanges. I noticed the
inconsistency when looking at our system log:
```
2026-03-12 05:36:48.600914 -0700 0x2e66: DIE has no address range information
2026-03-12 05:36:48.600950 -0700 0x2e8c: DIE has no address range information
2026-03-12 05:36:48.601068 -0700 DIE(0x1dc2): DIE has no address range information
2026-03-12 05:36:48.631000 -0700 DIE(0x80f4): DIE has no address range information
```
In #162162, I added support for OSC 9;4 graphical progress. I put it
behind the `show-progress` setting because I didn't have a reliable way
to detect whether the escape code was supported by the terminal.
Since then, more tools have added support for it, most notably Claude
Code and Homebrew. While I still don't have a good way to detect this,
there are a handful of known terminals that are easy enough to identify.
This PR toggles the default of `show-progress` to on again and puts
showing the progress behind a check for those known terminals (Windows
Terminal, ConEmu & Ghostty).
This means that if you're running in one of those, you'll get the visual
progress by default unless you set `show-progress` to off. The downside
is that if you're on an unrecognized terminal, you can't force it on any
longer by setting `show-progress` to on. I think that's a fair trade-off
as the setting wasn't really advertised and I doubt many people are
using that. As a workaround, they can set `OSC_PROGRESS` to spoof an
OSC-supporting terminal.
`<cstddef>` was included for static assertion using `offsetof()`, but it
turns out that the header is already included before. Thus remove
`<cstddef>` includes from `RegisterContextFreeBSDKernelCore_<arch>.cpp`
files.
Fixes 3f65a03e8abb3e6fb3372cf4c254d6c9f090e2e0 (#183969)
Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
pcb layout is not stable yet so it can be changed anytime on FreeBSD
side. Changes to pcb might not be reflected to FreeBSD source tree or
upstream LLDB possibly because the developer forgot to do so, which
breaks kernel debugging functionality. This patch adds assertion thus
LLDB cannot be built if its expected pcb layout doesn't match the real
one. This assertion is only enabled when the build machine architecture
matches `RegisterContextFreeBSDKernelCore_<arch>`.
Due to identifier conflict, I had to lower PCB_FP and PCB_LR.
---------
Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
Relocate HTTPClient and HTTPServer from the Debuginfod library to
llvm/Support/HTTP so they can be reused by other components.
---------
Relanding with fixes in CMakeLists.txt to account for dependency to new LLVMSupportHTTP in tools.
Relanding with one more fix in libSupportHTTP that adds it as a component in libLLVM.so
---------
Co-authored-by: Alexandre Ganea <aganea@havenstudios.com>
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
Relocate HTTPClient and HTTPServer from the Debuginfod library to
llvm/Support/HTTP so they can be reused by other components.
---------
Relanding with fixes in CMakeLists.txt to account for dependency to new
LLVMSupportHTTP in tools.
---------
Co-authored-by: Alexandre Ganea <aganea@havenstudios.com>
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
The `memory history` command was using `ToAddress` for its address
argument, which strips non-addressable bits (including MTE tag bits) via
`FixAnyAddress`. This caused us to pass a stripped address to
`__asan_get_alloc_stack`/`__asan_get_free_stack`, which is incorrect.
Switch to `ToRawAddress` to preserve the complete address, including the
MTE tag, so we can look up the correct address.
The code was declaring a shared poiner and then immediately trying to
dereference it to initialize it's contents, but the dereference was
giving a seg fault. This fixes that issue.
