date:20070621

Re: [Rd] segfault during cbind

2007-06-21 Thread Prof Brian Ripley

On Thu, 21 Jun 2007, Martin Morgan wrote:

> Yes, that seems to do the trick, for both seg fault and valgrind!
> Thanks very much.

Thanks: this and a similar one elsewhere seem long-standing bugs in bind.c
Will commit shortly.

>
> Martin
>
> Prof Brian Ripley <[EMAIL PROTECTED]> writes:
>
>> I think it needs to be
>>
>>  case LISTSXP:
>>  PROTECT(u = coerceVector(u, mode));
>>  k = LENGTH(u);
>>  idx = (!isMatrix(u)) ? rows : k;
>>  for (i = 0; i < idx; i++)
>>  SET_VECTOR_ELT(result, n++,
>> duplicate(VECTOR_ELT(u, i % k)));
>>  UNPROTECT(1);
>>  break;
>>
>> around 1258 in bind.c.  Can you test that please?
>>
>>
>> On Thu, 21 Jun 2007, Martin Morgan wrote:
>>
>>> The following code results in a seg fault.
>>>
 sessionInfo()
>>> R version 2.6.0 Under development (unstable) (2007-06-21 r42013)
>>> x86_64-unknown-linux-gnu
>>>
>>> locale:
>>> LC_CTYPE=en_US;LC_NUMERIC=C;LC_TIME=en_US;LC_COLLATE=en_US;LC_MONETARY=en_US;LC_MESSAGES=en_US;LC_PAPER=en_US;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US;LC_IDENTIFICATION=C
>>>
>>> attached base packages:
>>> [1] stats graphics  grDevices utils datasets  methods   base
 csvFile <- read.csv("Barley1.na22.annot.csv", as.is=TRUE, na.strings="---")
 probe <- csvFile[,1]
 gb <- csvFile[, 9]
 rm(csvFile)
 gb <- lapply(unlist(gb),
>>> +  function(x) toupper(strsplit(x,"\\.")[[1]][1]))
 id_file <- cbind(probe,gb)
>>>
>>> *** caught segfault ***
>>> address 0x2c9f0, cause 'memory not mapped'
>>>
>>> Traceback:
>>> 1: cbind(probe, gb)
>>> 2: makeBasefiles("Barley1.na22.annot.csv")
>>> aborting ...
>>> Segmentation fault
>>>
>>> valgrind says
>>>
>>> ==25398== Invalid read of size 8
>>> ==25398==at 0x4E7BB2D: cbind (bind.c:1258)
>>> ==25398==by 0x4E7B430: do_bind (bind.c:1113)
>>> ==25398==by 0x4F42A1B: do_internal (names.c:1116)
>>> ==25398==by 0x4EF959B: Rf_eval (eval.c:463)
>>> ==25398==by 0x4EF9F91: Rf_applyClosure (eval.c:666)
>>> ==25398==by 0x4EF988D: Rf_eval (eval.c:507)
>>> ==25398==by 0x4EFC3E0: do_set (eval.c:1404)
>>> ==25398==by 0x4EF959B: Rf_eval (eval.c:463)
>>> ==25398==by 0x4EFB866: do_begin (eval.c:1156)
>>> ==25398==by 0x4EF959B: Rf_eval (eval.c:463)
>>> ==25398==by 0x4EF9F91: Rf_applyClosure (eval.c:666)
>>> ==25398==by 0x4EF988D: Rf_eval (eval.c:507)
>>> ==25398==  Address 0x8F46010 is 72,976 bytes inside a block of size 182,760 
>>> free'd
>>> ==25398==at 0x4C226DB: free (in 
>>> /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
>>> ==25398==by 0x4F2D848: ReleaseLargeFreeVectors (memory.c:760)
>>> ==25398==by 0x4F359E9: RunGenCollect (memory.c:1378)
>>> ==25398==by 0x4F38938: R_gc_internal (memory.c:2171)
>>> ==25398==by 0x4F38046: Rf_allocVector (memory.c:1961)
>>> ==25398==by 0x4EDE779: duplicate1 (duplicate.c:221)
>>> ==25398==by 0x4EDD698: Rf_duplicate (duplicate.c:115)
>>> ==25398==by 0x4E7BB34: cbind (bind.c:1258)
>>> ==25398==by 0x4E7B430: do_bind (bind.c:1113)
>>> ==25398==by 0x4F42A1B: do_internal (names.c:1116)
>>> ==25398==by 0x4EF959B: Rf_eval (eval.c:463)
>>> ==25398==by 0x4EF9F91: Rf_applyClosure (eval.c:666)
>>>
>>> gdb says
>>>
>>> (gdb) backtrace
>>> #0  0x2b2dfe6940c9 in duplicate1 (s=0x2c9f0)
>>>at /home/mtmorgan/src/R-devel/src/main/duplicate.c:134
>>> #1  0x2b2dfe694035 in Rf_duplicate (s=0x2c9f0)
>>>at /home/mtmorgan/src/R-devel/src/main/duplicate.c:115
>>> #2  0x2b2dfe632555 in cbind (call=0xaaba48, args=0xb6abf0, mode=19,
>>>rho=0xb6ba40, deparse_level=1)
>>>at /home/mtmorgan/src/R-devel/src/main/bind.c:1263
>>> #3  0x2b2dfe631e51 in do_bind (call=0xaaba48, op=0x62f950, 
>>> args=0xb6abf0,
>>>env=0xb6ba40) at /home/mtmorgan/src/R-devel/src/main/bind.c:1113
>>> #4  0x2b2dfe6f93d4 in do_internal (call=0xaabab8, op=0x62d028,
>>>args=0xaaba10, env=0xb6ba40)
>>>at /home/mtmorgan/src/R-devel/src/main/names.c:1115
>>>
>>> and
>>>
>>> (gdb) up
>>> #2  0x2b2dfe632555 in cbind (call=0xaaba48, args=0xb6abf0, mode=19,
>>>rho=0xb6ba40, deparse_level=1)
>>>at /home/mtmorgan/src/R-devel/src/main/bind.c:1263
>>> (gdb) p i
>>> $7 = 22839
>>> (gdb) p idx
>>> $8 = 22840
>>>
>>> Both rm and lapply are needed to trigger the fault; an R level gc()
>>> before the final line 'cures' the fault (and the valgind complaint).
>>>
>>> The data file is available (with free registration) at
>>>
>>> https://www.affymetrix.com/support/file_download.affx?onloadforward=/analysis/downloads/na22/ivt/Barley1.na22.annot.csv.zip
>>>
>>> Martin
>>>
>>
>> --
>> Brian D. Ripley,  [EMAIL PROTECTED]
>> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
>> University of Oxford, Tel:  +44 1865 272861 (self)
>> 1 South Parks Road, +4

Re: [Rd] segfault during cbind

2007-06-21 Thread Martin Morgan

Yes, that seems to do the trick, for both seg fault and valgrind!
Thanks very much.

Martin

Prof Brian Ripley <[EMAIL PROTECTED]> writes:

> I think it needs to be
>
>   case LISTSXP:
>   PROTECT(u = coerceVector(u, mode));
>   k = LENGTH(u);
>   idx = (!isMatrix(u)) ? rows : k;
>   for (i = 0; i < idx; i++)
>   SET_VECTOR_ELT(result, n++,
>  duplicate(VECTOR_ELT(u, i % k)));
>   UNPROTECT(1);
>   break;
>
> around 1258 in bind.c.  Can you test that please?
>
>
> On Thu, 21 Jun 2007, Martin Morgan wrote:
>
>> The following code results in a seg fault.
>>
>>> sessionInfo()
>> R version 2.6.0 Under development (unstable) (2007-06-21 r42013)
>> x86_64-unknown-linux-gnu
>>
>> locale:
>> LC_CTYPE=en_US;LC_NUMERIC=C;LC_TIME=en_US;LC_COLLATE=en_US;LC_MONETARY=en_US;LC_MESSAGES=en_US;LC_PAPER=en_US;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US;LC_IDENTIFICATION=C
>>
>> attached base packages:
>> [1] stats graphics  grDevices utils datasets  methods   base
>>> csvFile <- read.csv("Barley1.na22.annot.csv", as.is=TRUE, na.strings="---")
>>> probe <- csvFile[,1]
>>> gb <- csvFile[, 9]
>>> rm(csvFile)
>>> gb <- lapply(unlist(gb),
>> +  function(x) toupper(strsplit(x,"\\.")[[1]][1]))
>>> id_file <- cbind(probe,gb)
>>
>> *** caught segfault ***
>> address 0x2c9f0, cause 'memory not mapped'
>>
>> Traceback:
>> 1: cbind(probe, gb)
>> 2: makeBasefiles("Barley1.na22.annot.csv")
>> aborting ...
>> Segmentation fault
>>
>> valgrind says
>>
>> ==25398== Invalid read of size 8
>> ==25398==at 0x4E7BB2D: cbind (bind.c:1258)
>> ==25398==by 0x4E7B430: do_bind (bind.c:1113)
>> ==25398==by 0x4F42A1B: do_internal (names.c:1116)
>> ==25398==by 0x4EF959B: Rf_eval (eval.c:463)
>> ==25398==by 0x4EF9F91: Rf_applyClosure (eval.c:666)
>> ==25398==by 0x4EF988D: Rf_eval (eval.c:507)
>> ==25398==by 0x4EFC3E0: do_set (eval.c:1404)
>> ==25398==by 0x4EF959B: Rf_eval (eval.c:463)
>> ==25398==by 0x4EFB866: do_begin (eval.c:1156)
>> ==25398==by 0x4EF959B: Rf_eval (eval.c:463)
>> ==25398==by 0x4EF9F91: Rf_applyClosure (eval.c:666)
>> ==25398==by 0x4EF988D: Rf_eval (eval.c:507)
>> ==25398==  Address 0x8F46010 is 72,976 bytes inside a block of size 182,760 
>> free'd
>> ==25398==at 0x4C226DB: free (in 
>> /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
>> ==25398==by 0x4F2D848: ReleaseLargeFreeVectors (memory.c:760)
>> ==25398==by 0x4F359E9: RunGenCollect (memory.c:1378)
>> ==25398==by 0x4F38938: R_gc_internal (memory.c:2171)
>> ==25398==by 0x4F38046: Rf_allocVector (memory.c:1961)
>> ==25398==by 0x4EDE779: duplicate1 (duplicate.c:221)
>> ==25398==by 0x4EDD698: Rf_duplicate (duplicate.c:115)
>> ==25398==by 0x4E7BB34: cbind (bind.c:1258)
>> ==25398==by 0x4E7B430: do_bind (bind.c:1113)
>> ==25398==by 0x4F42A1B: do_internal (names.c:1116)
>> ==25398==by 0x4EF959B: Rf_eval (eval.c:463)
>> ==25398==by 0x4EF9F91: Rf_applyClosure (eval.c:666)
>>
>> gdb says
>>
>> (gdb) backtrace
>> #0  0x2b2dfe6940c9 in duplicate1 (s=0x2c9f0)
>>at /home/mtmorgan/src/R-devel/src/main/duplicate.c:134
>> #1  0x2b2dfe694035 in Rf_duplicate (s=0x2c9f0)
>>at /home/mtmorgan/src/R-devel/src/main/duplicate.c:115
>> #2  0x2b2dfe632555 in cbind (call=0xaaba48, args=0xb6abf0, mode=19,
>>rho=0xb6ba40, deparse_level=1)
>>at /home/mtmorgan/src/R-devel/src/main/bind.c:1263
>> #3  0x2b2dfe631e51 in do_bind (call=0xaaba48, op=0x62f950, args=0xb6abf0,
>>env=0xb6ba40) at /home/mtmorgan/src/R-devel/src/main/bind.c:1113
>> #4  0x2b2dfe6f93d4 in do_internal (call=0xaabab8, op=0x62d028,
>>args=0xaaba10, env=0xb6ba40)
>>at /home/mtmorgan/src/R-devel/src/main/names.c:1115
>>
>> and
>>
>> (gdb) up
>> #2  0x2b2dfe632555 in cbind (call=0xaaba48, args=0xb6abf0, mode=19,
>>rho=0xb6ba40, deparse_level=1)
>>at /home/mtmorgan/src/R-devel/src/main/bind.c:1263
>> (gdb) p i
>> $7 = 22839
>> (gdb) p idx
>> $8 = 22840
>>
>> Both rm and lapply are needed to trigger the fault; an R level gc()
>> before the final line 'cures' the fault (and the valgind complaint).
>>
>> The data file is available (with free registration) at
>>
>> https://www.affymetrix.com/support/file_download.affx?onloadforward=/analysis/downloads/na22/ivt/Barley1.na22.annot.csv.zip
>>
>> Martin
>>
>
> -- 
> Brian D. Ripley,  [EMAIL PROTECTED]
> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel:  +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax:  +44 1865 272595

-- 
Martin Morgan
Bioconductor / Computational Biology
http://bioconductor.org

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mail

Re: [Rd] segfault during cbind

2007-06-21 Thread Prof Brian Ripley

I think it needs to be

case LISTSXP:
PROTECT(u = coerceVector(u, mode));
k = LENGTH(u);
idx = (!isMatrix(u)) ? rows : k;
for (i = 0; i < idx; i++)
SET_VECTOR_ELT(result, n++,
   duplicate(VECTOR_ELT(u, i % k)));
UNPROTECT(1);
break;

around 1258 in bind.c.  Can you test that please?


On Thu, 21 Jun 2007, Martin Morgan wrote:

> The following code results in a seg fault.
>
>> sessionInfo()
> R version 2.6.0 Under development (unstable) (2007-06-21 r42013)
> x86_64-unknown-linux-gnu
>
> locale:
> LC_CTYPE=en_US;LC_NUMERIC=C;LC_TIME=en_US;LC_COLLATE=en_US;LC_MONETARY=en_US;LC_MESSAGES=en_US;LC_PAPER=en_US;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US;LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>> csvFile <- read.csv("Barley1.na22.annot.csv", as.is=TRUE, na.strings="---")
>> probe <- csvFile[,1]
>> gb <- csvFile[, 9]
>> rm(csvFile)
>> gb <- lapply(unlist(gb),
> +  function(x) toupper(strsplit(x,"\\.")[[1]][1]))
>> id_file <- cbind(probe,gb)
>
> *** caught segfault ***
> address 0x2c9f0, cause 'memory not mapped'
>
> Traceback:
> 1: cbind(probe, gb)
> 2: makeBasefiles("Barley1.na22.annot.csv")
> aborting ...
> Segmentation fault
>
> valgrind says
>
> ==25398== Invalid read of size 8
> ==25398==at 0x4E7BB2D: cbind (bind.c:1258)
> ==25398==by 0x4E7B430: do_bind (bind.c:1113)
> ==25398==by 0x4F42A1B: do_internal (names.c:1116)
> ==25398==by 0x4EF959B: Rf_eval (eval.c:463)
> ==25398==by 0x4EF9F91: Rf_applyClosure (eval.c:666)
> ==25398==by 0x4EF988D: Rf_eval (eval.c:507)
> ==25398==by 0x4EFC3E0: do_set (eval.c:1404)
> ==25398==by 0x4EF959B: Rf_eval (eval.c:463)
> ==25398==by 0x4EFB866: do_begin (eval.c:1156)
> ==25398==by 0x4EF959B: Rf_eval (eval.c:463)
> ==25398==by 0x4EF9F91: Rf_applyClosure (eval.c:666)
> ==25398==by 0x4EF988D: Rf_eval (eval.c:507)
> ==25398==  Address 0x8F46010 is 72,976 bytes inside a block of size 182,760 
> free'd
> ==25398==at 0x4C226DB: free (in 
> /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
> ==25398==by 0x4F2D848: ReleaseLargeFreeVectors (memory.c:760)
> ==25398==by 0x4F359E9: RunGenCollect (memory.c:1378)
> ==25398==by 0x4F38938: R_gc_internal (memory.c:2171)
> ==25398==by 0x4F38046: Rf_allocVector (memory.c:1961)
> ==25398==by 0x4EDE779: duplicate1 (duplicate.c:221)
> ==25398==by 0x4EDD698: Rf_duplicate (duplicate.c:115)
> ==25398==by 0x4E7BB34: cbind (bind.c:1258)
> ==25398==by 0x4E7B430: do_bind (bind.c:1113)
> ==25398==by 0x4F42A1B: do_internal (names.c:1116)
> ==25398==by 0x4EF959B: Rf_eval (eval.c:463)
> ==25398==by 0x4EF9F91: Rf_applyClosure (eval.c:666)
>
> gdb says
>
> (gdb) backtrace
> #0  0x2b2dfe6940c9 in duplicate1 (s=0x2c9f0)
>at /home/mtmorgan/src/R-devel/src/main/duplicate.c:134
> #1  0x2b2dfe694035 in Rf_duplicate (s=0x2c9f0)
>at /home/mtmorgan/src/R-devel/src/main/duplicate.c:115
> #2  0x2b2dfe632555 in cbind (call=0xaaba48, args=0xb6abf0, mode=19,
>rho=0xb6ba40, deparse_level=1)
>at /home/mtmorgan/src/R-devel/src/main/bind.c:1263
> #3  0x2b2dfe631e51 in do_bind (call=0xaaba48, op=0x62f950, args=0xb6abf0,
>env=0xb6ba40) at /home/mtmorgan/src/R-devel/src/main/bind.c:1113
> #4  0x2b2dfe6f93d4 in do_internal (call=0xaabab8, op=0x62d028,
>args=0xaaba10, env=0xb6ba40)
>at /home/mtmorgan/src/R-devel/src/main/names.c:1115
>
> and
>
> (gdb) up
> #2  0x2b2dfe632555 in cbind (call=0xaaba48, args=0xb6abf0, mode=19,
>rho=0xb6ba40, deparse_level=1)
>at /home/mtmorgan/src/R-devel/src/main/bind.c:1263
> (gdb) p i
> $7 = 22839
> (gdb) p idx
> $8 = 22840
>
> Both rm and lapply are needed to trigger the fault; an R level gc()
> before the final line 'cures' the fault (and the valgind complaint).
>
> The data file is available (with free registration) at
>
> https://www.affymetrix.com/support/file_download.affx?onloadforward=/analysis/downloads/na22/ivt/Barley1.na22.annot.csv.zip
>
> Martin
>

-- 
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] segfault during cbind

2007-06-21 Thread Martin Morgan

To amend, the traceback is only

> Traceback:
>  1: cbind(probe, gb)
> aborting ...

Oops. Martin

Martin Morgan <[EMAIL PROTECTED]> writes:

> The following code results in a seg fault.
>
>> sessionInfo()
> R version 2.6.0 Under development (unstable) (2007-06-21 r42013) 
> x86_64-unknown-linux-gnu 
>
> locale:
> LC_CTYPE=en_US;LC_NUMERIC=C;LC_TIME=en_US;LC_COLLATE=en_US;LC_MONETARY=en_US;LC_MESSAGES=en_US;LC_PAPER=en_US;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US;LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base 
>> csvFile <- read.csv("Barley1.na22.annot.csv", as.is=TRUE, na.strings="---")
>> probe <- csvFile[,1]
>> gb <- csvFile[, 9]
>> rm(csvFile)
>> gb <- lapply(unlist(gb),
> +  function(x) toupper(strsplit(x,"\\.")[[1]][1]))
>> id_file <- cbind(probe,gb)
>
>  *** caught segfault ***
> address 0x2c9f0, cause 'memory not mapped'
>
> Traceback:
>  1: cbind(probe, gb)
>  2: makeBasefiles("Barley1.na22.annot.csv")
> aborting ...
> Segmentation fault
>
> valgrind says
>
> ==25398== Invalid read of size 8
> ==25398==at 0x4E7BB2D: cbind (bind.c:1258)
> ==25398==by 0x4E7B430: do_bind (bind.c:1113)
> ==25398==by 0x4F42A1B: do_internal (names.c:1116)
> ==25398==by 0x4EF959B: Rf_eval (eval.c:463)
> ==25398==by 0x4EF9F91: Rf_applyClosure (eval.c:666)
> ==25398==by 0x4EF988D: Rf_eval (eval.c:507)
> ==25398==by 0x4EFC3E0: do_set (eval.c:1404)
> ==25398==by 0x4EF959B: Rf_eval (eval.c:463)
> ==25398==by 0x4EFB866: do_begin (eval.c:1156)
> ==25398==by 0x4EF959B: Rf_eval (eval.c:463)
> ==25398==by 0x4EF9F91: Rf_applyClosure (eval.c:666)
> ==25398==by 0x4EF988D: Rf_eval (eval.c:507)
> ==25398==  Address 0x8F46010 is 72,976 bytes inside a block of size 182,760 
> free'd
> ==25398==at 0x4C226DB: free (in 
> /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
> ==25398==by 0x4F2D848: ReleaseLargeFreeVectors (memory.c:760)
> ==25398==by 0x4F359E9: RunGenCollect (memory.c:1378)
> ==25398==by 0x4F38938: R_gc_internal (memory.c:2171)
> ==25398==by 0x4F38046: Rf_allocVector (memory.c:1961)
> ==25398==by 0x4EDE779: duplicate1 (duplicate.c:221)
> ==25398==by 0x4EDD698: Rf_duplicate (duplicate.c:115)
> ==25398==by 0x4E7BB34: cbind (bind.c:1258)
> ==25398==by 0x4E7B430: do_bind (bind.c:1113)
> ==25398==by 0x4F42A1B: do_internal (names.c:1116)
> ==25398==by 0x4EF959B: Rf_eval (eval.c:463)
> ==25398==by 0x4EF9F91: Rf_applyClosure (eval.c:666)
>
> gdb says
>
> (gdb) backtrace
> #0  0x2b2dfe6940c9 in duplicate1 (s=0x2c9f0)
> at /home/mtmorgan/src/R-devel/src/main/duplicate.c:134
> #1  0x2b2dfe694035 in Rf_duplicate (s=0x2c9f0)
> at /home/mtmorgan/src/R-devel/src/main/duplicate.c:115
> #2  0x2b2dfe632555 in cbind (call=0xaaba48, args=0xb6abf0, mode=19, 
> rho=0xb6ba40, deparse_level=1)
> at /home/mtmorgan/src/R-devel/src/main/bind.c:1263
> #3  0x2b2dfe631e51 in do_bind (call=0xaaba48, op=0x62f950, args=0xb6abf0, 
> env=0xb6ba40) at /home/mtmorgan/src/R-devel/src/main/bind.c:1113
> #4  0x2b2dfe6f93d4 in do_internal (call=0xaabab8, op=0x62d028, 
> args=0xaaba10, env=0xb6ba40)
> at /home/mtmorgan/src/R-devel/src/main/names.c:1115
>
> and
>
> (gdb) up
> #2  0x2b2dfe632555 in cbind (call=0xaaba48, args=0xb6abf0, mode=19, 
> rho=0xb6ba40, deparse_level=1)
> at /home/mtmorgan/src/R-devel/src/main/bind.c:1263
> (gdb) p i
> $7 = 22839
> (gdb) p idx
> $8 = 22840
>
> Both rm and lapply are needed to trigger the fault; an R level gc()
> before the final line 'cures' the fault (and the valgind complaint).
>
> The data file is available (with free registration) at
>
> https://www.affymetrix.com/support/file_download.affx?onloadforward=/analysis/downloads/na22/ivt/Barley1.na22.annot.csv.zip
>
> Martin
> -- 
> Martin Morgan
> Bioconductor / Computational Biology
> http://bioconductor.org
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Martin Morgan
Bioconductor / Computational Biology
http://bioconductor.org

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Basic Question on error(_(...

2007-06-21 Thread Prof Brian Ripley


On Thu, 21 Jun 2007, Peter Dalgaard wrote:


[EMAIL PROTECTED] wrote:

I'm sorry to bother this list with such trivial questions, but I'm
trying to take Prof. Ripley's advice in porting some Lapack wrappers
into my own code, because they are not public.  I'm specifically
choosing programs from R-2.5.0/src/modules/lapack/Lapack.c.

I can't seem to understand the context in functions such as:


error(_("the leading minor of order %d is not positive
definite"),
  i);


in functions such as modLa_chol.  Is there some place I can look to
understand the usage of the underscore '_', or could someone explain
this to me?


This has to do with internationalization. It signifies that translations
are available for the error message, e.g. the file "de.po" in the R
sources has

#: src/modules/lapack/Lapack.c:629
#, c-format
msgid "the leading minor of order %d is not positive definite"
msgstr "der führende Minor der Ordnung %d ist nicht positiv definit"


The answer to 'where' is section 1.9 Localization in 'Writing R 
Extensions' or section 3.1 of 'R Internals'.




--
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] segfault during cbind

2007-06-21 Thread Martin Morgan

The following code results in a seg fault.

> sessionInfo()
R version 2.6.0 Under development (unstable) (2007-06-21 r42013) 
x86_64-unknown-linux-gnu 

locale:
LC_CTYPE=en_US;LC_NUMERIC=C;LC_TIME=en_US;LC_COLLATE=en_US;LC_MONETARY=en_US;LC_MESSAGES=en_US;LC_PAPER=en_US;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US;LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base 
> csvFile <- read.csv("Barley1.na22.annot.csv", as.is=TRUE, na.strings="---")
> probe <- csvFile[,1]
> gb <- csvFile[, 9]
> rm(csvFile)
> gb <- lapply(unlist(gb),
+  function(x) toupper(strsplit(x,"\\.")[[1]][1]))
> id_file <- cbind(probe,gb)

 *** caught segfault ***
address 0x2c9f0, cause 'memory not mapped'

Traceback:
 1: cbind(probe, gb)
 2: makeBasefiles("Barley1.na22.annot.csv")
aborting ...
Segmentation fault

valgrind says

==25398== Invalid read of size 8
==25398==at 0x4E7BB2D: cbind (bind.c:1258)
==25398==by 0x4E7B430: do_bind (bind.c:1113)
==25398==by 0x4F42A1B: do_internal (names.c:1116)
==25398==by 0x4EF959B: Rf_eval (eval.c:463)
==25398==by 0x4EF9F91: Rf_applyClosure (eval.c:666)
==25398==by 0x4EF988D: Rf_eval (eval.c:507)
==25398==by 0x4EFC3E0: do_set (eval.c:1404)
==25398==by 0x4EF959B: Rf_eval (eval.c:463)
==25398==by 0x4EFB866: do_begin (eval.c:1156)
==25398==by 0x4EF959B: Rf_eval (eval.c:463)
==25398==by 0x4EF9F91: Rf_applyClosure (eval.c:666)
==25398==by 0x4EF988D: Rf_eval (eval.c:507)
==25398==  Address 0x8F46010 is 72,976 bytes inside a block of size 182,760 
free'd
==25398==at 0x4C226DB: free (in 
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==25398==by 0x4F2D848: ReleaseLargeFreeVectors (memory.c:760)
==25398==by 0x4F359E9: RunGenCollect (memory.c:1378)
==25398==by 0x4F38938: R_gc_internal (memory.c:2171)
==25398==by 0x4F38046: Rf_allocVector (memory.c:1961)
==25398==by 0x4EDE779: duplicate1 (duplicate.c:221)
==25398==by 0x4EDD698: Rf_duplicate (duplicate.c:115)
==25398==by 0x4E7BB34: cbind (bind.c:1258)
==25398==by 0x4E7B430: do_bind (bind.c:1113)
==25398==by 0x4F42A1B: do_internal (names.c:1116)
==25398==by 0x4EF959B: Rf_eval (eval.c:463)
==25398==by 0x4EF9F91: Rf_applyClosure (eval.c:666)

gdb says

(gdb) backtrace
#0  0x2b2dfe6940c9 in duplicate1 (s=0x2c9f0)
at /home/mtmorgan/src/R-devel/src/main/duplicate.c:134
#1  0x2b2dfe694035 in Rf_duplicate (s=0x2c9f0)
at /home/mtmorgan/src/R-devel/src/main/duplicate.c:115
#2  0x2b2dfe632555 in cbind (call=0xaaba48, args=0xb6abf0, mode=19, 
rho=0xb6ba40, deparse_level=1)
at /home/mtmorgan/src/R-devel/src/main/bind.c:1263
#3  0x2b2dfe631e51 in do_bind (call=0xaaba48, op=0x62f950, args=0xb6abf0, 
env=0xb6ba40) at /home/mtmorgan/src/R-devel/src/main/bind.c:1113
#4  0x2b2dfe6f93d4 in do_internal (call=0xaabab8, op=0x62d028, 
args=0xaaba10, env=0xb6ba40)
at /home/mtmorgan/src/R-devel/src/main/names.c:1115

and

(gdb) up
#2  0x2b2dfe632555 in cbind (call=0xaaba48, args=0xb6abf0, mode=19, 
rho=0xb6ba40, deparse_level=1)
at /home/mtmorgan/src/R-devel/src/main/bind.c:1263
(gdb) p i
$7 = 22839
(gdb) p idx
$8 = 22840

Both rm and lapply are needed to trigger the fault; an R level gc()
before the final line 'cures' the fault (and the valgind complaint).

The data file is available (with free registration) at

https://www.affymetrix.com/support/file_download.affx?onloadforward=/analysis/downloads/na22/ivt/Barley1.na22.annot.csv.zip

Martin
-- 
Martin Morgan
Bioconductor / Computational Biology
http://bioconductor.org

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Basic Question on error(_(...

2007-06-21 Thread Peter Dalgaard

[EMAIL PROTECTED] wrote:
> I'm sorry to bother this list with such trivial questions, but I'm
> trying to take Prof. Ripley's advice in porting some Lapack wrappers
> into my own code, because they are not public.  I'm specifically
> choosing programs from R-2.5.0/src/modules/lapack/Lapack.c.  
>
> I can't seem to understand the context in functions such as:
>
> 
> error(_("the leading minor of order %d is not positive
> definite"),
>   i);
>  
>
> in functions such as modLa_chol.  Is there some place I can look to
> understand the usage of the underscore '_', or could someone explain
> this to me?
>   
This has to do with internationalization. It signifies that translations 
are available for the error message, e.g. the file "de.po" in the R 
sources has

#: src/modules/lapack/Lapack.c:629
#, c-format
msgid "the leading minor of order %d is not positive definite"
msgstr "der führende Minor der Ordnung %d ist nicht positiv definit"

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Basic Question on error(_(...

2007-06-21 Thread statmobile

I'm sorry to bother this list with such trivial questions, but I'm
trying to take Prof. Ripley's advice in porting some Lapack wrappers
into my own code, because they are not public.  I'm specifically
choosing programs from R-2.5.0/src/modules/lapack/Lapack.c.  

I can't seem to understand the context in functions such as:


error(_("the leading minor of order %d is not positive
definite"),
  i);
 

in functions such as modLa_chol.  Is there some place I can look to
understand the usage of the underscore '_', or could someone explain
this to me?

Thanks for the help!

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] extending package with function calling an Objective Caml program

2007-06-21 Thread Prof Brian Ripley

On Wed, 20 Jun 2007, Tamara Steijger wrote:

> Hallo,
>
> we are trying to extend the R package multcompView in agreement with
> the author Hans-Peter Piepho. The function multcompLetters implements
> so far a heuristic. We would like to add a function that implements
> an exact algorithm and returns a provable optimum result. This
> algorithm has been implemented in Objective Caml and we would like to
> reuse this code. We wrote an R function that accepts the same input
> as the original function and provides the same result format. But
> this function calls the Obejctive Caml executable. This means that if
> the package is extended with this function the Objective Caml code
> has to be included as well and one needs to assure that it is
> compiled the right way if the package is loaded.
>
> Unfortunately are we not that familiar with R and could not find
> corresponding information in the documentation. Does somebody know if
> something as described above is possible? And where information could
> be found about how to do it?

It is possible, and the information is in 'Writing R Extensions'.

You would need to use configure to test if an OCaml compiler was 
installed, a src/Makefile to arrange to compile the executable and put it 
under inst/ so it would get installed.

Having said that, the chances that an R user would have an OCaml compiler 
installed seem to me to be very low, and it might be better to arrange to 
distribute pre-compiled versions of your package for platforms for which 
you can build it: preferably i686 and x86_64 Linux, Windows and MacOS X.

A variation on the last approach is to include prebuilt executables in the 
source package, and get configure to choose the right one to be installed 
if no OCaml compiler was found.

> Thanks,
> Tamara Steijger

-- 
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] extending package with function calling an Objective Caml program

2007-06-21 Thread Tamara Steijger

Hallo,

we are trying to extend the R package multcompView in agreement with  
the author Hans-Peter Piepho. The function multcompLetters implements  
so far a heuristic. We would like to add a function that implements  
an exact algorithm and returns a provable optimum result. This  
algorithm has been implemented in Objective Caml and we would like to  
reuse this code. We wrote an R function that accepts the same input  
as the original function and provides the same result format. But  
this function calls the Obejctive Caml executable. This means that if  
the package is extended with this function the Objective Caml code  
has to be included as well and one needs to assure that it is  
compiled the right way if the package is loaded.

Unfortunately are we not that familiar with R and could not find  
corresponding information in the documentation. Does somebody know if  
something as described above is possible? And where information could  
be found about how to do it?

Thanks,
Tamara Steijger

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] segfault during cbind

Re: [Rd] segfault during cbind

Re: [Rd] segfault during cbind

Re: [Rd] segfault during cbind

Re: [Rd] Basic Question on error(_(...

[Rd] segfault during cbind

Re: [Rd] Basic Question on error(_(...

[Rd] Basic Question on error(_(...

Re: [Rd] extending package with function calling an Objective Caml program

[Rd] extending package with function calling an Objective Caml program

10 matches

Site Navigation

Mail list logo

Footer information