public inbox for [email protected]  
help / color / mirror / Atom feed
From: Peter Eisentraut <[email protected]>
To: Fujii Masao <[email protected]>
To: Tom Lane <[email protected]>
Cc: [email protected]
Subject: Re: maximum number of backtrace frames logged by backtrace_functions
Date: Wed, 23 Mar 2022 14:04:47 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

On 18.02.22 17:05, Fujii Masao wrote:
>>> Or even backtrace should be logged by write_stderr() so that it's 
>>> written to eventlog if necessary? I just wonder why 
>>> backtrace_symbols_fd() is used only in ExceptionalCondition().
>>
>> Probably because it was simpler.  It would also make sense to convert 
>> the whole thing to use write_stderr() consistently.
> +1
> Attached is the updated version of the patch that uses write_stderr() to 
> log the backtrace in assertion failure case.
> 
> +        if (nframes >= lengthof(buf))
> +            appendStringInfo(&errtrace, "\n(backtrace limited to %zu 
> frames)",
> +                             lengthof(buf));

I think this should actually print nframes, because that's the actual 
number of frames returned.

> I found this doesn't work on FreeBSD, at least FreeBSD 13 that cfbot 
> uses on Cirrus CI. When the backtrace is larger than 100, on FreeBSD, 
> backtrace() seems to write the *99* (not 100) most recent function calls 
> to the buffer. That is, the variable "nframes" is 99 while lengthof(buf) 
> indicates 100. So the above message about backtrace limit will never be 
> logged on FreeBSD. OTOH, on Linux and MacOS, backtrace() writes the 100 
> most recent function calls. I'm not sure if such a behavior on FreeBSD 
> is expected or a bug.

Well, the API is that you ask for up to N frames, and it gives you X 
frames back.  There is no requirement that X is as close to N as 
possible.  But that also means that there is no portable API for finding 
out how many X it could give you if you had enough room (other than by 
looping and doubling the buffer dynamically etc.).

Maybe we can catch this particular case if we made the condition

     if (nframes >= lengthof(buf) - 1)

That might give slightly misleading information if you have exactly 99 
or 100 frames, but overall it might still be better.






reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: maximum number of backtrace frames logged by backtrace_functions
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox