I am debugging a program in GDB on linux. I am using getenv
and setenv
calls to read and set environment variables. For example I am calling setenv("TZ", "UTC", 1);
to set the TZ environment variable for timezone.
To check if the env variable is set I am using GDB command show environment
. This prints all the environment variables and their values. But it dose not show TZ
being set.
Even command show environment TZ
says Environment variable "TZ" not defined.
Is their another way to check the environment of the debugged program?
p *(char *) getenv("TZ")
reuturns correct value UTC
.
The ptype [ARG] command will print the type. Show activity on this post. This question may be related: vtable in polymorphic class of C++ using gdb: (gdb) help set print object Set printing of object's derived type based on vtable info.
Use the "info threads" command to see the IDs of currently known threads. The GDB thread debugging facility allows you to observe all threads while your program runs--but whenever GDB takes control, one thread in particular is always the focus of debugging. This thread is called the current thread.
The gdb command show environment
shows an environment which belongs to gdb
[see note], not the environment of the program being debugged.
Calling getenv
seems like a totally reasonable approach to printing the running program's environment.
Gdb maintains an environment array, initially copied from its own environment, which it uses to start each new child process. show environment
and set environment
work on this environment, so set environment
will change an environment variable for the next time you start the program being debugged. Once the program is started, the loader will have copied the environment into the program's address space, and any changes made with setenv
apply to that array, not the one maintained by gdb
.
On Linux, every process's environment is available through the pseudofile /proc/PID/environ
, where PID
is replaced by the pid of the process. The value of that file is a list of null-terminated strings, so printing it out takes a small amount of work.
Inside gdb, once you've started running the program to be debugged, you can get its pid with info proc
and then use that to print the entire environment:
(gdb) info proc
process 6074
...
(gdb) shell xargs -0 printf %s\\n < /proc/6074/environ
XDG_VTNR=7
KDE_MULTIHEAD=false
...
Of course, I could have done that just as easily outside of gdb, from a different terminal.
You can alter GDB's view of the environment with set environment TZ =UTC
but that doesn't affect a running program, only the environment that will be used next time an inferior process is started.
You can inspect a running inferior process' current environment via the global variable environ
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With