On Tue, Sep 5, 2023 at 2:59 AM Alvaro Herrera wrote:
> Much appreciated! I can put this to good use.
I was just reminded of how our existing backtrace support is lacklustre.
Are you planning on submitting a patch for this?
--
Peter Geoghegan
On 2023-Sep-04, Noah Misch wrote:
> On Mon, Jul 03, 2023 at 11:58:25AM +0200, Alvaro Herrera wrote:
> > Agreed, these backtraces are pretty close to useless. Not completely,
> > but I haven't found a practical way to use them for actual debugging
> > of production problems.
>
> For what it's wo
On Mon, Jul 03, 2023 at 11:58:25AM +0200, Alvaro Herrera wrote:
> On 2023-Jul-02, Andres Freund wrote:
> > I like that we now have a builtin backtrace ability. Unfortunately I think
> > the
> > backtraces are often not very useful, because only externally visible
> > functions are symbolized.
>
>
On Mon Jul 3, 2023 at 12:43 PM CDT, Andres Freund wrote:
> On 2023-07-03 11:58:25 +0200, Alvaro Herrera wrote:
> > On 2023-Jul-02, Andres Freund wrote:
> > > Nice things about libbacktrace are that the generation of stack traces is
> > > documented to be async signal safe on most platforms (with a
Hi,
On 2023-07-03 11:58:25 +0200, Alvaro Herrera wrote:
> On 2023-Jul-02, Andres Freund wrote:
> > I like that we now have a builtin backtrace ability. Unfortunately I think
> > the
> > backtraces are often not very useful, because only externally visible
> > functions are symbolized.
>
> Agreed
On 02.07.23 20:31, Andres Freund wrote:
A lot of platforms have "libbacktrace" available, e.g. as part of gcc. I think
we should consider using it, when available, to produce more useful
backtraces.
I hacked it up for ereport() to debug something, and the backtraces are
considerably better:
Ma
On 7/3/23 11:58, Alvaro Herrera wrote:
Nice things about libbacktrace are that the generation of stack traces is
documented to be async signal safe on most platforms (with a #define to figure
that out, and a more minimal safe version always available) and that it
supports a wide range of platfo
Hello,
On 2023-Jul-02, Andres Freund wrote:
> I like that we now have a builtin backtrace ability. Unfortunately I think the
> backtraces are often not very useful, because only externally visible
> functions are symbolized.
Agreed, these backtraces are pretty close to useless. Not completely,
At Sun, 2 Jul 2023 11:31:56 -0700, Andres Freund wrote in
> The state I currently have is very hacky, but if there's interest in
> upstreaming something like this, I could clean it up.
I can't help voting +1.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
On 7/2/23 14:31, Andres Freund wrote:
Nice things about libbacktrace are that the generation of stack traces is
documented to be async signal safe on most platforms (with a #define to figure
that out, and a more minimal safe version always available) and that it
supports a wide range of platforms
ne 2. 7. 2023 v 20:32 odesílatel Andres Freund napsal:
> Hi,
>
> I like that we now have a builtin backtrace ability. Unfortunately I think
> the
> backtraces are often not very useful, because only externally visible
> functions are symbolized.
>
> E.g.:
>
> 2023-07-02 10:54:01.756 PDT [1398494]
Hi,
I like that we now have a builtin backtrace ability. Unfortunately I think the
backtraces are often not very useful, because only externally visible
functions are symbolized.
E.g.:
2023-07-02 10:54:01.756 PDT [1398494][client backend][:0][[unknown]] LOG: will
crash
2023-07-02 10:54:01.756
12 matches
Mail list logo
