Thread: [PATCH] Fix for crash while deleting rows on 64 bit systems
I believe I've fixed a problem where pgAdmin intermittently crashes on 64 bit systems while deleting rows. The issues seems to be that, among other things, sqlTable::DeleteRows() in frm/frmEditGrid.cpp attempts to remove an element in lineIndex by shifting down the remaining elements. Unfortunately the "sizeof" is taking the size of the wrong thing. I suspect this is only an issue on systems where pointers and "int"s are different sizes, which should be 64 bit systems, but I have only have a 64 bit Linux system handy to try. Increasing the number of rows that follow the row deleted should increase the probability of getting a crash, but Valgrind always complains about bad reads and writes for the memmove() in question. Steps to reproduce the problem: 1) Choose a table that has roughly 200 or more rows. Here's a dump of such a table: http://selliott.org/pgadmin/table-200-rows.sql 2) Navigate to the "Edit Data" window (the window navigated to by selecting the View Data / View All Rows for the table in question). 3) Select a low numbered row, such as the fifth row. 4) Right click and select "Delete". The crash may happen when the delete is confirmed after the subsequent dialog. -- ------------------------------------------------------------------------ | Steven Elliott | http://selliott.org | selliott4@austin.rr.com | ------------------------------------------------------------------------
Attachment
On Sun, 2012-03-18 at 11:37 -0500, Steven Elliott wrote: > I believe I've fixed a problem where pgAdmin intermittently crashes on > 64 bit systems while deleting rows. The issues seems to be that, among > other things, sqlTable::DeleteRows() in frm/frmEditGrid.cpp attempts to > remove an element in lineIndex by shifting down the remaining elements. > Unfortunately the "sizeof" is taking the size of the wrong thing. > > I suspect this is only an issue on systems where pointers and "int"s are > different sizes, which should be 64 bit systems, but I have only have a > 64 bit Linux system handy to try. > > Increasing the number of rows that follow the row deleted should > increase the probability of getting a crash, but Valgrind always > complains about bad reads and writes for the memmove() in question. > > Steps to reproduce the problem: > 1) Choose a table that has roughly 200 or more rows. Here's a dump of > such a table: > http://selliott.org/pgadmin/table-200-rows.sql > 2) Navigate to the "Edit Data" window (the window navigated to by > selecting the View Data / View All Rows for the table in question). > 3) Select a low numbered row, such as the fifth row. > 4) Right click and select "Delete". The crash may happen when the > delete is confirmed after the subsequent dialog. > Quite impressive. I found this bug a few days ago and was unable to fix it. So thank you very much. I applied it. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
On Sun, 2012-03-18 at 23:31 +0100, Guillaume Lelarge wrote: > On Sun, 2012-03-18 at 11:37 -0500, Steven Elliott wrote: > > I believe I've fixed a problem where pgAdmin ... > > Quite impressive. I found this bug a few days ago and was unable to fix > it. So thank you very much. I applied it. No problem. I'm glad I could help. It was a tricky problem in that attempting investigate the point where the segfault happens makes no sense. Variables have strange values that should not be possible. I have to credit Valgrind. Without it problems like this are very difficult to track down. -- ------------------------------------------------------------------------ | Steven Elliott | http://selliott.org | selliott4@austin.rr.com | ------------------------------------------------------------------------