Thread: line numbers in error messages are off wrt debuggers

Hi,

I'm fairly frequently annoyed that when I see an error message in the
log, I can't just generally set a breakpoint on the included line
number. That's because the line number in the error message is from the
*end* of the message:

2018-06-20 09:02:39.226 PDT [21145][3/2] LOG:  00000: statement: SELECT 1;
2018-06-20 09:02:39.226 PDT [21145][3/2] LOCATION:  exec_simple_query, postgres.c:952

corresponds to

        ereport(LOG,
                (errmsg("statement: %s", query_string),
                 errhidestmt(true),
                 errdetail_execute(parsetree_list)));

with 952 being the line with the semicolon.

Are others bothered by this?

If so, does anybody have a handle how we could get a more useful line
number out of the preprocessor?

Greetings,

Andres Freund

Andres Freund <andres@anarazel.de> writes:
> I'm fairly frequently annoyed that when I see an error message in the
> log, I can't just generally set a breakpoint on the included line
> number. That's because the line number in the error message is from the
> *end* of the message:

IME it varies depending on which compiler you use; some report the line
where the ereport is.  So I'm doubtful that there's going to be much we
can do about it.  Probably this behavior is bound up with macro expansion
vs. just when __LINE__ is expanded.

(No, I won't hold still for a coding requirement that all ereport calls
be smashed onto a single line ;-))

Personally, my habit is to set the breakpoint at errfinish, which works
independently of just where the call is.

            regards, tom lane

Hi,

On 2018-06-20 12:12:26 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > I'm fairly frequently annoyed that when I see an error message in the
> > log, I can't just generally set a breakpoint on the included line
> > number. That's because the line number in the error message is from the
> > *end* of the message:
> 
> IME it varies depending on which compiler you use; some report the line
> where the ereport is.  So I'm doubtful that there's going to be much we
> can do about it.  Probably this behavior is bound up with macro expansion
> vs. just when __LINE__ is expanded.
> 
> (No, I won't hold still for a coding requirement that all ereport calls
> be smashed onto a single line ;-))

Hah, me neither ;)


> Personally, my habit is to set the breakpoint at errfinish, which works
> independently of just where the call is.

I do that too, occasionally. Doesn't really if there's a lot of error
messages before the bug you're waiting for happens though.

Greetings,

Andres Freund

On 2018-06-20 12:12:26 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > I'm fairly frequently annoyed that when I see an error message in the
> > log, I can't just generally set a breakpoint on the included line
> > number. That's because the line number in the error message is from the
> > *end* of the message:
> 
> IME it varies depending on which compiler you use; some report the line
> where the ereport is.  So I'm doubtful that there's going to be much we
> can do about it.  Probably this behavior is bound up with macro expansion
> vs. just when __LINE__ is expanded.

Seems it can be hacked around: https://stackoverflow.com/a/13497879

But yikes, that's ugly.

There's apparenty some discussion in the standard committees trying to
unify the behaviour across compilers, but ...

Greetings,

Andres Freund

Andres Freund <andres@anarazel.de> writes:
> On 2018-06-20 12:12:26 -0400, Tom Lane wrote:
>> Personally, my habit is to set the breakpoint at errfinish, which works
>> independently of just where the call is.

> I do that too, occasionally. Doesn't really if there's a lot of error
> messages before the bug you're waiting for happens though.

Yeah.  In principle you could make the breakpoint conditional, looking
at the saved line number in the error stack, which *would* match the
log data.  There'd be a small chance of false matches (same line # in
another file), but that'd filter it pretty well most times.

            regards, tom lane

Andres Freund <andres@anarazel.de> writes:
> Seems it can be hacked around: https://stackoverflow.com/a/13497879
> But yikes, that's ugly.

I bet it's not very portable either.  I'm not sure that all compilers
will think that HANDLEARGS should be expanded in that situation.

            regards, tom lane