Bug#616180: Old GCC bug affecting postgresql error handling
On Wed, Nov 06, 2013 at 02:20:18PM +, Ian Jackson wrote: Tom Lane writes (Re: Old GCC bug affecting postgresql error handling): Ian Jackson ijack...@chiark.greenend.org.uk writes: I wasn't able to do a test of the actual current postgresql with a current Debian compiler. The original report is on sparc64 which is a bit difficult as I can't find any sparc64 porter box. Well, I certainly hope current Postgres would not show the bug, regardless of gcc's whims ;-). We have those extra return statements in there now, and also in current sources there's been an attempt to teach the compiler that ereport(ERROR) doesn't return anyway, via __builtin_unreachable() or local equivalent. I remain concerned that there may be other places exhibiting bugs with the same cause, but I'm pretty sure we've masked the division-by-zero symptom. Indeed. If I had the time and resources I might try seeing if current postgresql can be persuaded to re-exhibit this bug with a modern compiler by reverting some of the return statements put in as a workaround for this bug. But I don't. I have just tried on sparc64 machine with a sparc64 chroot. The problem is still reproducible with gcc 4.4, but not with latest versions (tested with 4.6 and 4.8). Given gcc 4.8 is the default on sparc64, I guess we can really consider the problem as fixed. Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616180: Old GCC bug affecting postgresql error handling
Tom Lane writes (Re: Old GCC bug affecting postgresql error handling): Ian Jackson ijack...@chiark.greenend.org.uk writes: Alex Deiter appears to have tried to report this to gcc upstream: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29968 However, the test program in that bugzilla report is indeed broken. The gcc maintainers were right to reject the bug. Hm --- it's a bit questionable. The test execution appears to show that the side-effect of program abort happens before the printf call; but depending on how much buffering of stdout is happening, it might not really prove that. As it happens in actual fact in the example program, the stdout output is indeed buffered so the observed behaviour is exactly what one would expect if the program had been compiled naively without any optimisation. However, also, undefined behaviour doesn't respect causality. If your program's behaviour is ever undefined, the whole behaviour is undefined. (C99 3.4.3.) So even if you made stdout unbuffered, or wrote to stderr, the same observed behaviour is permissible. Your version is a lot more conclusive, at least as far as Postgres' issue is concerned, because in our case we know the ereport() function won't return. Right. I have tried to reproduce the original problem with a smaller test program (see below) than postgresql, but failed (on 32-bit sparc with gcc 4.4.5-8, Debian squeeze). I wonder whether the gcc folk reconsidered and fixed the problem somewhere between 4.1.x and 4.4.x. I've seen them reverse course before on what was or wasn't a bug. I wasn't able to do a test of the actual current postgresql with a current Debian compiler. The original report is on sparc64 which is a bit difficult as I can't find any sparc64 porter box. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616180: Old GCC bug affecting postgresql error handling
Ian Jackson ijack...@chiark.greenend.org.uk writes: Tom Lane writes (Re: Old GCC bug affecting postgresql error handling): I wonder whether the gcc folk reconsidered and fixed the problem somewhere between 4.1.x and 4.4.x. I've seen them reverse course before on what was or wasn't a bug. I wasn't able to do a test of the actual current postgresql with a current Debian compiler. The original report is on sparc64 which is a bit difficult as I can't find any sparc64 porter box. Well, I certainly hope current Postgres would not show the bug, regardless of gcc's whims ;-). We have those extra return statements in there now, and also in current sources there's been an attempt to teach the compiler that ereport(ERROR) doesn't return anyway, via __builtin_unreachable() or local equivalent. I remain concerned that there may be other places exhibiting bugs with the same cause, but I'm pretty sure we've masked the division-by-zero symptom. regards, tom lane -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616180: Old GCC bug affecting postgresql error handling
Tom Lane writes (Re: Old GCC bug affecting postgresql error handling): Ian Jackson ijack...@chiark.greenend.org.uk writes: I wasn't able to do a test of the actual current postgresql with a current Debian compiler. The original report is on sparc64 which is a bit difficult as I can't find any sparc64 porter box. Well, I certainly hope current Postgres would not show the bug, regardless of gcc's whims ;-). We have those extra return statements in there now, and also in current sources there's been an attempt to teach the compiler that ereport(ERROR) doesn't return anyway, via __builtin_unreachable() or local equivalent. I remain concerned that there may be other places exhibiting bugs with the same cause, but I'm pretty sure we've masked the division-by-zero symptom. Indeed. If I had the time and resources I might try seeing if current postgresql can be persuaded to re-exhibit this bug with a modern compiler by reverting some of the return statements put in as a workaround for this bug. But I don't. Regards, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616180: Old GCC bug affecting postgresql error handling
I recently came across this bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616180
This relates to a gcc optimisation bug affecting postgresql error
handling. (It was reported there in Debian on Sparc in gcc 4.x.)
Assumign that the ereport function/macro used there doesn't return, I
agree that this is a gcc bug not a postgresql bug.
Alex Deiter appears to have tried to report this to gcc upstream:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29968
However, the test program in that bugzilla report is indeed broken.
The gcc maintainers were right to reject the bug.
I have tried to reproduce the original problem with a smaller test
program (see below) than postgresql, but failed (on 32-bit sparc with
gcc 4.4.5-8, Debian squeeze).
(AIUI we don't have a sparc64 porter box or chroot that I could try.)
Regards,
Ian.
/* t.c */
#include stdio.h
#include t.h
int main(int argc, char **argv) {
int divisor = atoi(argv[1]);
if (!divisor)
quit_program();
printf(%d\n, 42/divisor);
return 0;
}
/* u.c */
#include stdlib.h
void x(void) { strtoul('-1',0,0); }
/* t.h */
#include stdio.h
#include stdlib.h
void quit_program(void);
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616180: Old GCC bug affecting postgresql error handling
Ian Jackson ijack...@chiark.greenend.org.uk writes: I recently came across this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616180 This relates to a gcc optimisation bug affecting postgresql error handling. (It was reported there in Debian on Sparc in gcc 4.x.) Assumign that the ereport function/macro used there doesn't return, I agree that this is a gcc bug not a postgresql bug. Well, that's what I think anyway ;-) Alex Deiter appears to have tried to report this to gcc upstream: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29968 However, the test program in that bugzilla report is indeed broken. The gcc maintainers were right to reject the bug. Hm --- it's a bit questionable. The test execution appears to show that the side-effect of program abort happens before the printf call; but depending on how much buffering of stdout is happening, it might not really prove that. Your version is a lot more conclusive, at least as far as Postgres' issue is concerned, because in our case we know the ereport() function won't return. I have tried to reproduce the original problem with a smaller test program (see below) than postgresql, but failed (on 32-bit sparc with gcc 4.4.5-8, Debian squeeze). I wonder whether the gcc folk reconsidered and fixed the problem somewhere between 4.1.x and 4.4.x. I've seen them reverse course before on what was or wasn't a bug. regards, tom lane -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
