Thread: Infinity bsearch crash on Windows
A 9.1Beta1 test report from Richard Broersma (and confirmed on another system by Mark Watson) showed up pgsql-testers this week at http://archives.postgresql.org/pgsql-testers/2011-05/msg00000.php with the following test crashing his Windows server every time: SELECT 'INFINITY'::TIMESTAMP; That works fine for me on Linux. Richard chased the error in the logs, which was a generic "you can't touch that memory" one, down to a full stack trace: http://archives.postgresql.org/pgsql-testers/2011-05/msg00009.php It looks like it's losing its mind inside of src/backend/utils/adt/datetime.c , specifically at this line in datebsearch: 3576 while (last >= base) 3577 { 3578 position = base + ((last - base) >> 1); 3579 result= key[0] - position->token[0]; Why crash there only on Windows? Was the problem actually introduced above this part of the code? These are all questions I have no answer for. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
On 10 May 2011 23:02, Greg Smith <greg@2ndquadrant.com> wrote: > Why crash there only on Windows? Was the problem actually introduced above > this part of the code? These are all questions I have no answer for. I don't find it at all surprising that there's a memory corruption bug that only manifests itself on Windows. Recently, I reported a bug in pgAdmin that turned out to be a simple case of forgetting to allocate an extra byte of memory for a null in a c string. The outward problem couldn't be reproduced on Mac - it only occurred on Linux. Of course, the problem with undefined behaviour is not that it might cause your program to crash, but that it might not cause your program to crash. For debug builds, Visual C++ allocates "no man's land" guard bytes on either side of areas of allocated memory, which is great for catching heap corruption bugs. My guess is that when the VC++ debugger issues a breakpoint, that's exactly where the memory is being corrupted/improperly dereferenced. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services
Greg Smith <greg@2ndQuadrant.com> writes: > A 9.1Beta1 test report from Richard Broersma (and confirmed on another > system by Mark Watson) showed up pgsql-testers this week at > http://archives.postgresql.org/pgsql-testers/2011-05/msg00000.php with > the following test crashing his Windows server every time: > SELECT 'INFINITY'::TIMESTAMP; Hmm ... I bet this is related to the recent reports about ALTER USER VALID UNTIL 'infinity' crashing on Windows. Can the people seeing this get through the regression tests? Perhaps more to the point, what is their setting of TimeZone? What does the pg_timezone_abbrevs view show for them? regards, tom lane
Tom Lane wrote: >> SELECT 'INFINITY'::TIMESTAMP; >> > > Hmm ... I bet this is related to the recent reports about ALTER USER > VALID UNTIL 'infinity' crashing on Windows. Can the people seeing this > get through the regression tests? Perhaps more to the point, what is > their setting of TimeZone? What does the pg_timezone_abbrevs view show > for them? > I must have missed that thread, I think I'm missing one of these lists (pgsql-bugs maybe?). I've cc'd Mark Watson so maybe you can get better responses without me in the middle if needed; for this one, he reports: Show timezone gives US/Eastern Select * from pg_timezone_abbrevs returns zero rows My Linux system that doesn't have this problem is also in US/Eastern, too, but I get 189 rows in pg_timezone_abrevs. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
Greg Smith <greg@2ndquadrant.com> writes: > I must have missed that thread, I think I'm missing one of these lists > (pgsql-bugs maybe?). I've cc'd Mark Watson so maybe you can get better > responses without me in the middle if needed; for this one, he reports: > Show timezone gives US/Eastern > Select * from pg_timezone_abbrevs returns zero rows Yeah, the latter confirms my theory about what's going wrong. See http://archives.postgresql.org/message-id/17311.1305080416@sss.pgh.pa.us and recent commits. regards, tom lane