Обсуждение: 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