search

kylemaxxwell / rpostgresql

Automatically exported from code.google.com/p/rpostgresql
0 stars 0 forks source link

Mac OS X 10.6.4 PostgreSQL 9.0 Beta 3 & 8.4.4 Crash on test selectWhereZero.R #19

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
-------------- versions                                      
----------------------
ProductName:    Mac OS X
ProductVersion: 10.6.4
BuildVersion:   10F569
RPostgreSQL svn version: 132:134
psql (PostgreSQL) 9.0beta3

R version 2.11.1 (2010-05-31) 
x86_64-apple-darwin9.8.0 

locale:

Package: RPostgreSQL
Version: 0.1-6
Packaged: NA
Built: R 2.11.1; universal-apple-darwin9.8.0; 2010-08-24 16:29:16 UTC;

--------------start RPostgreSQL/tests/selectWhereZero.R      
----------------------
Loading required package: RPostgreSQL
Loading required package: DBI
./check_with_vars.sh: line 74:  5075 Abort trap              R --arch=i386 
--slave < RPostgreSQL/tests/selectWhereZero.R

Original issue reported on code.google.com by ne...@neiltiffin.com on 24 Aug 2010 at 4:35

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
meant to say, it also fails on:

-------------- versions                                      
----------------------
ProductName:    Mac OS X
ProductVersion: 10.6.4
BuildVersion:   10F569
RPostgreSQL svn version: 132:134
psql (PostgreSQL) 8.4.4

R version 2.11.1 (2010-05-31) 
x86_64-apple-darwin9.8.0 

locale:

Package: RPostgreSQL
Version: 0.1-6
Packaged: NA
Built: R 2.11.1; universal-apple-darwin9.8.0; 2010-08-24 18:49:08 UTC;

Original comment by ne...@neiltiffin.com on 24 Aug 2010 at 6:52

GoogleCodeExporter commented 9 years ago 
Although, it does not reproduce on my machine. Reading the code, there are a 
lot of places without proper buffer length check.  Some buffers seems enough, 
but 256 bytes for error messages will be too short in fact. As seen from the 
output the buffer should have as long as the followign message. A better hint 
with the new version
may have hit the size limit.

could not Retrieve the result : ERROR:  operator does not exist: text = integer
LINE 1: select * from tmpirisdata where Species=0
                                               ^
HINT:  No operator matches the given name and argument type(s). You might need 
to add explicit type casts.

I changed this for dynamic allocation. Other parts were just changed sprintf() 
to snprintf() to guarantee that the constructed string fits in the buffer size.
Please check if this works.

Original comment by tomoa...@kenroku.kanazawa-u.ac.jp on 12 Sep 2010 at 2:56

Attachments:

GoogleCodeExporter commented 9 years ago 
This keeps it from aborting on OS X

-------------- version info ----------------------
ProductName:    Mac OS X
ProductVersion: 10.6.4
BuildVersion:   10F569
RPostgreSQL svn version: 141M
psql (PostgreSQL) 9.0beta3

R version 2.11.1 (2010-05-31) 
x86_64-apple-darwin9.8.0 

locale:
[1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8

Package: RPostgreSQL
Version: 0.1-7
Packaged: NA
Built: R 2.11.1; universal-apple-darwin9.8.0; 2010-09-12 15:47:27 UTC;

--------------start RPostgreSQL/tests/selectWhereZero.R      
----------------------
Loading required package: RPostgreSQL
Loading required package: DBI
Error in postgresqlExecStatement(conn, statement, ...) : 
  RS-DBI driver: (could not Retrieve the result : ERROR:  operator does not exist: text = integer
LINE 1: select * from tmpirisdata where Species=0
                                               ^
HINT:  No operator matches the given name and argument type(s). You might need 
to add explicit type casts.
)
NULL
[1] "Removing tmpirisdata\n"
[1] TRUE
Warning message:
In postgresqlQuickSQL(conn, statement, ...) :
  Could not create executeselect * from tmpirisdata where Species=0

Original comment by ne...@neiltiffin.com on 12 Sep 2010 at 3:49

GoogleCodeExporter commented 9 years ago 
Now, it looks that it shows a proper error message instead of aborting due to 
buffer overflow.
selectWhereZero.R is presumably introduced to detect abortion due to buffer 
overflow on wrong SQL command failing. Since the SQL is anyway a failing 
command, showing error message is the right thing.  So, I believe issue 6 and 
19 are fixed. I am not sure on issue 11 because there is not enough detail to 
know what happened, but it may also disappear.

Original comment by tomoa...@kenroku.kanazawa-u.ac.jp on 12 Sep 2010 at 4:25

GoogleCodeExporter commented 9 years ago 
Fixed with r143.

Original comment by ne...@neiltiffin.com on 12 Sep 2010 at 4:51