Date:   Sat, 11 Mar 2023 17:36:46 +0000
From:   Daniel Thompson <daniel.thompson@linaro.org>
To:     Randy Dunlap <rdunlap@infradead.org>
Cc:     Ajay Garg <ajaygargnsit@gmail.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Jason Wessel <jason.wessel@windriver.com>,
        Douglas Anderson <dianders@chromium.org>,
        kgdb-bugreport-request@lists.sourceforge.net
Subject: Re: How to resolve "nptl-signals.h : no such file or directory"
Message-ID: <20230311173646.GA4559@aspen.lan>
References: <CAHP4M8UEnLeTbrR1fZOJ2KkRAHLJLewjT2xg78AzzoXPYcz-hA@mail.gmail.com>
 <b6530d49-074d-ee68-ed87-57c9d60d4847@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b6530d49-074d-ee68-ed87-57c9d60d4847@infradead.org>
Precedence: bulk

On Sat, Mar 11, 2023 at 08:52:53AM -0800, Randy Dunlap wrote:
> +add some kernel gdb people + list

This looks like a userspace backtrace to me, so rather off-topic for
LKML but since I've read it already...


> On 3/11/23 08:00, Ajay Garg wrote:
> > Hi All.
> >
> > (Sorry had to write to this list, as the subscription to
> > gdb@sourcewave.org seemingly went successful, but never got the
>
> Is that  @sourceware.org ?
>
> > confirmation email. Even sending emails get bounced).
> >
> >
> > I have been trying to analyze a core, but unable to receive the
> > complete backtrace due to following error :
> >
> > #######################################
> > #0  0x0088ad6c in __libc_signal_restore_set (set=0xf48f2a78) at
> > ../sysdeps/unix/sysv/linux/nptl-signals.h:79
> > 79 ../sysdeps/unix/sysv/linux/nptl-signals.h: No such file or directory.
> > #######################################

This is not why you are getting an incomplete backtrace!


> > Following is the (incomplete) backtrace :
> >
> > #######################################
> > [Current thread is 1 (LWP 7491)]
> > (gdb) bt
> > #0  0x0088ad6c in __libc_signal_restore_set (set=0xf48f2a78) at
> > ../sysdeps/unix/sysv/linux/nptl-signals.h:79
> > #1  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:48
> > #2  0x0088cb78 in __GI_abort () at abort.c:89

Frames 0-2 tell use your program called abort() (e.g. you got a core
dump because whatever you were running *asked* for a core dump to be
made)..

> > #3  <frame with modified names> 0x049b3a54 in func_1 (ffp=<optimized
> > out>, base_name=<optimized out>, max_size=<optimized out>,
> > file_type=<optimized out>)  at a/b/c/d/e:58

Not sure if this is good or bad but...

> > #4  0x00000270 in ?? ()

... based on the address here I'd say that this stack from is for a
function provided by your application... and you forgot to compile the
application with debug information!


Daniel.