From: Aditya Kamath <Aditya.Kamath1@ibm.com>
To: Keith Seitz <keiths@redhat.com>,
Aditya Vidyadhar Kamath <akamath996@gmail.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: RE: [PATCH] Fix crash in AIX when current working directory is NULL
Date: Wed, 24 Jun 2026 11:50:01 +0000 [thread overview]
Message-ID: <LV8PR15MB64884DBF4B23F939D161EB14D6ED2@LV8PR15MB6488.namprd15.prod.outlook.com> (raw)
In-Reply-To: <3ae0f8af-b88a-4f51-bce8-19be9b404fa0@redhat.com>
[-- 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 --]
next prev parent reply other threads:[~2026-06-24 11:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-22 9:11 Aditya Vidyadhar Kamath
2026-06-23 17:10 ` Keith Seitz
2026-06-24 11:50 ` Aditya Kamath [this message]
2026-06-26 14:56 ` Tom Tromey
2026-06-29 12:35 ` Aditya Kamath
2026-06-26 16:15 ` Ulrich Weigand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=LV8PR15MB64884DBF4B23F939D161EB14D6ED2@LV8PR15MB6488.namprd15.prod.outlook.com \
--to=aditya.kamath1@ibm.com \
--cc=akamath996@gmail.com \
--cc=gdb-patches@sourceware.org \
--cc=keiths@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox