[PATCH] Fix crash in AIX when current working directory is NULL

[PATCH] Fix crash in AIX when current working directory is NULL

[Aditya Vidyadhar Kamath]

From: Aditya Kamath <Aditya.Kamath1@ibm.com>

In AIX if we cannot read in the current directory we get,

gdb ~/gdb_tests/simple_test
gdb: warning: error finding working directory: A parameter must be a directory.
GNU gdb (GDB) 18.0.50.20260619-git
Copyright (C) 2026 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.
Type "show copying" and "show warranty" for details.
This GDB was configured as "powerpc64-ibm-aix7.2.0.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.

+------------------------------------------------------------------------------+
| Find the GDB manual online at:                                               |
| http://www.gnu.org/software/gdb/documentation/.                              |
| For help, type "help".                                                       |
| Type "apropos word" to search for commands related to "word".                |
+------------------------------------------------------------------------------+

Reading symbols from //gdb_tests/simple_test...
terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string: construction from null is not valid

Fatal signal: IOT/Abort trap
----- Backtrace -----
0x100943f1b gdb_internal_backtrace_1
        //home/binutils-gdb/gdb/bt-utils.c:122
0x100944027 _Z22gdb_internal_backtracev
        //home/binutils-gdb/gdb/bt-utils.c:173
0x10060faa7 handle_fatal_signal
        //home/binutils-gdb/gdb/event-top.c:1008
0x4fdf ???
---------------------
A fatal error internal to GDB has been detected, further
debugging is not possible.  GDB will now terminate.

This is a bug, please report it.  For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.

=============================

The reason for the same above is that in AIX, the variable current_directory in dwarf2/read.c
can be NULL if getcwd () fails during GDB initialisation. When this happens the dwarf2_per_bfd
construction initialisation list captured_cwd to NULL resulting in this segmentation fault shown above.

There are two reasons this happened:
1: The current working directory got deleted in another terminal.
2: Insufficient permission to read the current directory or its parent/predicissor directory.

This patch is a fix to the same.

Afer this fix we get GDB loaded correctly.
gdb ~/gdb_tests/simple_test
gdb: warning: error finding working directory: A parameter must be a directory.
GNU gdb (GDB) 18.0.50.20260619-git
Copyright (C) 2026 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.
Type "show copying" and "show warranty" for details.
This GDB was configured as "powerpc64-ibm-aix7.2.0.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.

+------------------------------------------------------------------------------+
| Find the GDB manual online at:                                               |
| http://www.gnu.org/software/gdb/documentation/.                              |
| For help, type "help".                                                       |
| Type "apropos word" to search for commands related to "word".                |
+------------------------------------------------------------------------------+

Reading symbols from //gdb_tests/simple_test...
(gdb) q
---
 gdb/dwarf2/read.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 84b1480dbcb..7962acc784d 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -859,7 +859,7 @@ dwarf2_per_bfd::dwarf2_per_bfd (bfd *obfd, const dwarf2_debug_sections *names,
 				bool can_copy_)
   : obfd (obfd),
     can_copy (can_copy_),
-    captured_cwd (current_directory),
+    captured_cwd (current_directory == NULL ? "" : current_directory),
     captured_debug_dir (debug_file_directory)
 {
   if (names == NULL)
-- 
2.51.2

Re: [PATCH] Fix crash in AIX when current working directory is NULL

[Keith Seitz]

Hi,

On 6/22/26 2:11 AM, Aditya Vidyadhar Kamath wrote:
> From: Aditya Kamath <Aditya.Kamath1@ibm.com>
> 
> In AIX if we cannot read in the current directory we get,
> 

Thank you for the patch. I can confirm that this is independent of
architecture/OS. On x86_64 Fedora 43, we can also demonstrate the issue:

term1$ pwd
/home/keiths/tmp
term1$ mkdir gone && cd gone
term2$ rm -rf ~/tmp/gone
term1$ gdb -nx -q ~/tmp/simple
/home/keiths/gdb: ⚠️ warning: error finding working directory: No such 
file or directory
Reading symbols from /home/keiths/tmp/simple...
terminate called after throwing an instance of 'std::logic_error'
   what():  basic_string: construction from null is not valid

We've seen a number of similar issues throughout the years. Is it
possible to write a test for this?

> The reason for the same above is that in AIX, the variable current_directory in dwarf2/read.c
> can be NULL if getcwd () fails during GDB initialisation. When this happens the dwarf2_per_bfd
> construction initialisation list captured_cwd to NULL resulting in this segmentation fault shown above.

I apologize for being pedantic, but this is more accurately described as 
a (abort due to a) std::logic_error.

> There are two reasons this happened:
> 1: The current working directory got deleted in another terminal.
> 2: Insufficient permission to read the current directory or its parent/predicissor directory.

Typo "predicissor". Did you mean "predecessor?"

> 
> This patch is a fix to the same.
> 
> Afer this fix we get GDB loaded correctly.

Typo "After"

> gdb ~/gdb_tests/simple_test
> gdb: warning: error finding working directory: A parameter must be a directory.
> GNU gdb (GDB) 18.0.50.20260619-git
> Copyright (C) 2026 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.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "powerpc64-ibm-aix7.2.0.0".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <https://www.gnu.org/software/gdb/bugs/>.
> 
> +------------------------------------------------------------------------------+
> | Find the GDB manual online at:                                               |
> | http://www.gnu.org/software/gdb/documentation/.                              |
> | For help, type "help".                                                       |
> | Type "apropos word" to search for commands related to "word".                |
> +------------------------------------------------------------------------------+
> 
> Reading symbols from //gdb_tests/simple_test...
> (gdb) q
> ---
>   gdb/dwarf2/read.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
> index 84b1480dbcb..7962acc784d 100644
> --- a/gdb/dwarf2/read.c
> +++ b/gdb/dwarf2/read.c
> @@ -859,7 +859,7 @@ dwarf2_per_bfd::dwarf2_per_bfd (bfd *obfd, const dwarf2_debug_sections *names,
>   				bool can_copy_)
>     : obfd (obfd),
>       can_copy (can_copy_),
> -    captured_cwd (current_directory),
> +    captured_cwd (current_directory == NULL ? "" : current_directory),

Please use "nullptr" instead.

>       captured_debug_dir (debug_file_directory)
>   {
>     if (names == NULL)

While this fix does catch this one specific place, I wonder if this bug
lurks elsewhere. For example, in main.c, when getcwd() is called and
returns NULL, gdb warns the user and leaves current_directory as NULL.

Changing that so that current_directory isn't NULL also fixes this
problem and could prevent(?) other similar problems. Of course, that
kind of change could introduce some sort of API semantic inconsistencies
with current_directory which likely would require more (invasive)
changes.

In any case, I am just asking. Your patch is simple and minimally
invasive. Nonetheless, if it is possible, I would really like a
test for this.

Keith

RE: [PATCH] Fix crash in AIX when current working directory is NULL

[Aditya Kamath]

[-- Attachment #1: Type: text/plain, Size: 1816 bytes --]

Hi Keith,

Thank you for your review.

>Thank you for the patch. I can confirm that this is independent of
>architecture/OS. On x86_64 Fedora 43, we can also demonstrate the issue:
>Is it
>possible to write a test for this?
>I apologize for being pedantic, but this is more accurately described as
>a (abort due to a) std::logic_error.
>Typo "predicissor". Did you mean "predecessor?”
>Typo “After"
>Please use "nullptr" instead.

Sure. I will fix all the typos and make a small test case in v2 of this patch [in gdb.base test suite]. Will be changing the heading as well since this is a problem in many other targets.

But I have one question below before I send a v2 of this patch.

>While this fix does catch this one specific place, I wonder if this bug
>lurks elsewhere. For example, in main.c, when getcwd() is called and
>returns NULL, gdb warns the user and leaves current_directory as NULL.
>Changing that so that current_directory isn't NULL also fixes this
>problem and could prevent(?) other similar problems. Of course, that
>kind of change could introduce some sort of API semantic inconsistencies
>with current_directory which likely would require more (invasive)
>changes.

I did test other places where getcwd () is used. But the only thing is it is not causing any crash. I could not produce a similar issue when getcwd () is not able to get the current directory for any reason due to other files using getcwd().

What do you think is the best thing we can do? Should we then change the main.c file as well to handle getcwd () failing to make it uniform everywhere in GDB wherever possible since we are thinking there will be a way by which one can run into similar issue due to the same?

Kindly let me know. Have a nice day ahead.

Thanks and regards,
Aditya.

[-- Attachment #2: Type: text/html, Size: 4271 bytes --]

Re: [PATCH] Fix crash in AIX when current working directory is NULL

[Tom Tromey]

> I did test other places where getcwd () is used. But the only thing is
> it is not causing any crash. I could not produce a similar issue when
> getcwd () is not able to get the current directory for any reason due
> to other files using getcwd().

> What do you think is the best thing we can do? Should we then change
> the main.c file as well to handle getcwd () failing to make it uniform
> everywhere in GDB wherever possible since we are thinking there will
> be a way by which one can run into similar issue due to the same?

FWIW there's also this bug:

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

and this old thread:

    https://sourceware.org/pipermail/gdb-patches/2026-January/224101.html

Maybe we should have just landed this earlier rather than asking to fix
it in a real way.

It's not totally clear to me what a good approach might be.
Like there's no good default to use when getcwd fails.  Maybe "/"?

Tom

Re: [PATCH] Fix crash in AIX when current working directory is NULL

[Ulrich Weigand]

Aditya Vidyadhar Kamath wrote:  

>diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c  
>index 84b1480dbcb..7962acc784d 100644  
>--- a/gdb/dwarf2/read.c  
>+++ b/gdb/dwarf2/read.c  
>@@ -859,7 +859,7 @@ dwarf2_per_bfd::dwarf2_per_bfd (bfd *obfd, const
>dwarf2_debug_sections *names,  
>  bool can_copy_) 
>   : obfd (obfd),  
>     can_copy (can_copy_),  
>-    captured_cwd (current_directory),  
>+    captured_cwd (current_directory == NULL ? "" :
current_directory),  
>     captured_debug_dir (debug_file_directory)  

The captured_cwd logic was introduced by Tom Tromey in
commit 3fbf1a34f10aa6a67d9f96c437e8f9dc57832d22.  Previously,
in the case where current_directory == NULL, that NULL pointer
was passed directly to openp, which passes it on to gdb_abspath.

That latter routine does in fact has extra code handling a NULL
cwd input (basically treating any input path as absolute).
This is different from how an empty string as cwd input is
handled (for an empty string, it looks like an extra '/'
is prepended).

So even with this proposed patch, we'd still have a change in
behavior (though no longer a crash) as compared to the version
before Tom's commit above.

Tom, any thoughts on how this should be handled?  Should we
add another check when passing captured_cwd to openp?
Change captured_cwd to something like std::optional<std::string>?

Bye,
Ulrich

RE: [PATCH] Fix crash in AIX when current working directory is NULL

[Aditya Kamath]

[-- Attachment #1: Type: text/plain, Size: 5459 bytes --]

Hi Tom, Ulrich, Keith and community members,

Thank you very much for the feedback so far.

From my analysis, we have two choices either we can use NULL when getcwd () fails to return the path or pass an empty string “”.

If we pass NULL, absolute paths will work correctly from what I have seen in the code. Relative paths will be returned as is since they won’t work as getcwd () failed because someone deleted the directory or permission issues.

std::string
gdb_abspath (const char *path, const char *cwd)
{
  gdb_assert (path != NULL && path[0] != '\0');

  if (path[0] == '~')
    return gdb_tilde_expand (path);

  if (IS_ABSOLUTE_PATH (path) || cwd == NULL)
    return path;

Since we passed NULL the above code will return as is.

If we pass “” an empty string, absolute paths will work correctly. Relative paths get that “/“ prepended and that is misleading since it gives the impression that the file is in root which is wrong especially if I am a non-root user.

return path_join (cwd, path);

In the above function the cwd size is one and a “/“ is appended.

I think it is better we keep it NULL and treat it as absolute, which is saying do not modify the path, but it won’t work.

>So even with this proposed patch, we'd still have a change in
>behavior (though no longer a crash) as compared to the version
>before Tom's commit above.

>Tom, any thoughts on how this should be handled?  Should we
>add another check when passing captured_cwd to openp?
>Change captured_cwd to something like std::optional<std::string>?


As Ulrich suggested,
This is what I tried. If getcwd () fails, then we can set the captured_cwd to std::nullopt.

bash-5.3# git diff
diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 7962acc784d..07668fdae0f 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -859,7 +859,9 @@ dwarf2_per_bfd::dwarf2_per_bfd (bfd *obfd, const dwarf2_debug_sections *names,
                                bool can_copy_)
   : obfd (obfd),
     can_copy (can_copy_),
-    captured_cwd (current_directory == NULL ? "" : current_directory),
+    captured_cwd (current_directory != nullptr
+                 ? std::optional<std::string> (current_directory)
+                 : std::nullopt),
     captured_debug_dir (debug_file_directory)
 {
   if (names == NULL)
@@ -6735,7 +6737,10 @@ try_open_dwop_file (dwarf2_per_bfd *per_bfd, const char *file_name, int is_dwp,

   gdb::unique_xmalloc_ptr<char> absolute_name;
   desc = openp (search_path, flags, file_name, O_RDONLY | O_BINARY,
-               &absolute_name, per_bfd->captured_cwd.c_str ());
+  &absolute_name,
+  per_bfd->captured_cwd.has_value ()
+    ? per_bfd->captured_cwd->c_str ()
+    : nullptr);
   if (desc < 0)
     return NULL;

diff --git a/gdb/dwarf2/read.h b/gdb/dwarf2/read.h
index 15dd2abf3a1..308c34bf66a 100644
--- a/gdb/dwarf2/read.h
+++ b/gdb/dwarf2/read.h
@@ -757,8 +757,10 @@ struct dwarf2_per_bfd
     abstract_to_concrete;

   /* Current directory, captured at the moment that object this was
-     created.  */
-  std::string captured_cwd;
+     created.  If nullopt, the working directory was unavailable
+     which means getcwd failed either due to directory deletion or
+     permission issues. So paths should be treated as absolute.  */
+  std::optional<std::string> captured_cwd;
   /* Captured copy of debug_file_directory.  */
   std::string captured_debug_dir;
 };

Let me know what you think. I have also written a small test for the same which I will share in v2 of this patch.

Thanks and regards,
Aditya.


From: Tom Tromey <tom@tromey.com>
Date: Friday, 26 June 2026 at 8:26 PM
To: Aditya Kamath <Aditya.Kamath1@ibm.com>
Cc: Keith Seitz <keiths@redhat.com>; Aditya Vidyadhar Kamath <akamath996@gmail.com>; gdb-patches@sourceware.org <gdb-patches@sourceware.org>
Subject: [EXTERNAL] Re: [PATCH] Fix crash in AIX when current working directory is NULL

> I did test other places where getcwd () is used. But the only thing is
> it is not causing any crash. I could not produce a similar issue when
> getcwd () is not able to get the current directory for any reason due
> to other files using getcwd().

> What do you think is the best thing we can do? Should we then change
> the main.c file as well to handle getcwd () failing to make it uniform
> everywhere in GDB wherever possible since we are thinking there will
> be a way by which one can run into similar issue due to the same?

FWIW there's also this bug:

    https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceware.org_bugzilla_show-5Fbug.cgi-3Fid-3D33799&d=DwIBAg&c=BSDicqBQBDjDI9RkVyTcHQ&r=f-oUQ8ByG1nZ71OI9p76qywCPh7mxzU69hBYnkP9Nis&m=pJwL-Vnh-wHy-ucvQkCCQdhJiMWffoiz7VA4n_dsjvagFcH7Lw3IGVhD5KK-jOs9&s=X51HmYNP3w7pGGi7hkHlxGZFXEabCWJcJh1PVg7Bii4&e=

and this old thread:

    https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceware.org_pipermail_gdb-2Dpatches_2026-2DJanuary_224101.html&d=DwIBAg&c=BSDicqBQBDjDI9RkVyTcHQ&r=f-oUQ8ByG1nZ71OI9p76qywCPh7mxzU69hBYnkP9Nis&m=pJwL-Vnh-wHy-ucvQkCCQdhJiMWffoiz7VA4n_dsjvagFcH7Lw3IGVhD5KK-jOs9&s=91CwpHnJX6riwMO8LtJnkP9926u_Wn1BZVemfT8vPLs&e=

Maybe we should have just landed this earlier rather than asking to fix
it in a real way.

It's not totally clear to me what a good approach might be.
Like there's no good default to use when getcwd fails.  Maybe "/"?

Tom

[-- Attachment #2: Type: text/html, Size: 20472 bytes --]