[BUG #17888] Incorrect memory access in gist__int_ops for an input array with many elements
От | Ankit Kumar Pandey |
---|---|
Тема | [BUG #17888] Incorrect memory access in gist__int_ops for an input array with many elements |
Дата | |
Msg-id | 796b65c3-57b7-bddf-b0d5-a8afafb8b627@gmail.com обсуждение исходный текст |
Ответы |
Re: [BUG #17888] Incorrect memory access in gist__int_ops for an input array with many elements
|
Список | pgsql-hackers |
Hi, I was looking at this issue: https://www.postgresql.org/message-id/flat/17888-f72930e6b5ce8c14%40postgresql.org pfree call on contrib/intarray/_int_gist.c:345 ``` if (in != (ArrayType *) DatumGetPointer(entry->key)) pfree(in); ``` leads to BogusFree function call and server crash. This is when we use array size of 1001. If we increase array size to 3001, we get index size error, NOTICE: input array is too big (199 maximum allowed, 3001 current), use gist__intbig_ops opclass instead ERROR: index row requires 12040 bytes, maximum size is 8191 When array size is 1001 is concerned, we raise elog about input array is too big, multiple of times. Wouldn't it make more sense to error out instead of proceeding further and getting bogus pointer errors messages (as we do when size is 3001)? Changing elog to ereport makes behavior consistent (between array size of 1001 vs 3001), so I have attached a patch for that. It errors out like this: ERROR: input array is too big (199 maximum allowed, 1001 current), use gist__intbig_ops opclass instead This is same error which was raised as notice earlier. Let me know if it makes sense. Also, comments on BogusFree mentions `As a possible aid in debugging, we report the header word along with the pointer address`. How can we interpret useful debugging information from this? `pfree called with invalid pointer 0x7ff1706d0030 (header 0x4fc8000100000000)` Regards, Ankit
Вложения
В списке pgsql-hackers по дате отправления: