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