Re: [Rd] valgrind complains about regex.c (PR#8043)
Prof Brian Ripley wrote: > Did you compile R without optimization? Such reads are often the result > of read-aheads produced by the optimizer in an attempt to keep > pipelines full (and are harmless). There were both a read and a write. I can see the read being harmless, but is the write harmless? I suspect this may be the bug I fixed on July 16, since it had to do with character classes including ranges (like Charlie's "[a-pr-z]"). Charlie, have you tried a recent version of R-patched? Duncan Murdoch > > On an un-optimized build of R I am unable to reproduce this. (I also was > unable to reproduce it on my optimized build of 2.1.1 using gcc 3.4.4, > although I did get a report on other read-aheads.) > > On Mon, 1 Aug 2005 [EMAIL PROTECTED] wrote: > > >>I think I am using objects according to the man page. >>This seems to be a valid regular expression. But whether >>I know what I'm doing or no, it still shouldn't be doing >>what valgrind seems to be saying it's doing. (IMHO) > > > I think you need to take that up with compiler designers: it is common > practice. > > >>-- start of script -- >>Script started on Mon 01 Aug 2005 02:09:00 PM PDT >>linux$ printenv VALGRIND_OPTS >>--tool=3Dmemcheck >>linux$ cat bar.R >> >>foo <- 1 >>bar <- 2:3 >>baz <- 4:6 >>qux <- matrix(7:10, 2) >> >>ls() >>rm(list =3D objects(pattern =3D "^[a-pr-z]")) >>ls() >> >>linux$ R --version >>R 2.1.1 (2005-06-20). >>Copyright (C) 2005 R Development Core Team >> >>R is free software and comes with ABSOLUTELY NO WARRANTY. >>You are welcome to redistribute it under the terms of the GNU >>General Public License. For more information about these matters, >>see http://www.gnu.org/copyleft/gpl.html. >>linux$ gcc --version >>=1B[0mgcc (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux) >>=1B[0mCopyright (C) 2003 Free Software Foundation, Inc. >>=1B[0mThis is free software; see the source for copying conditions. There = >>is NO >>=1B[0mwarranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PU= >>RPOSE. >>=1B[0m >>linux$ cat /etc/SuSE-release=20 >>SuSE Linux 9.3 (i586) >>VERSION =3D 9.3 >>linux$ R --vanilla --debugger=3Dvalgrind < bar.R >| bar.Rout >>=3D=3D22324=3D=3D Memcheck, a memory error detector for x86-linux. >>=3D=3D22324=3D=3D Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward = >>et al. >>=3D=3D22324=3D=3D Using valgrind-2.2.0, a program supervision framework for= >>x86-linux. >>=3D=3D22324=3D=3D Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward = >>et al. >>=3D=3D22324=3D=3D For more details, rerun with: -v >>=3D=3D22324=3D=3D=20 >>=3D=3D22324=3D=3D Invalid read of size 4 >>=3D=3D22324=3D=3Dat 0x81255AD: parse_expression (regex.c:5045) >>=3D=3D22324=3D=3Dby 0x8125868: parse_branch (regex.c:4475) >>=3D=3D22324=3D=3Dby 0x8125913: parse_reg_exp (regex.c:4420) >>=3D=3D22324=3D=3Dby 0x81261B3: Rf_regcomp (regex.c:4384) >>=3D=3D22324=3D=3D Address 0x1C1E23A8 is 0 bytes after a block of size 32 a= >>lloc'd >>=3D=3D22324=3D=3Dat 0x1B90650D: calloc (in /usr/lib/valgrind/vgpreload_= >>memcheck.so) >>=3D=3D22324=3D=3Dby 0x81247B5: parse_expression (regex.c:5406) >>=3D=3D22324=3D=3Dby 0x8125868: parse_branch (regex.c:4475) >>=3D=3D22324=3D=3Dby 0x8125913: parse_reg_exp (regex.c:4420) >>=3D=3D22324=3D=3D=20 >>=3D=3D22324=3D=3D Invalid write of size 4 >>=3D=3D22324=3D=3Dat 0x81255B2: parse_expression (regex.c:5045) >>=3D=3D22324=3D=3Dby 0x8125868: parse_branch (regex.c:4475) >>=3D=3D22324=3D=3Dby 0x8125913: parse_reg_exp (regex.c:4420) >>=3D=3D22324=3D=3Dby 0x81261B3: Rf_regcomp (regex.c:4384) >>=3D=3D22324=3D=3D Address 0x1C1E23A8 is 0 bytes after a block of size 32 a= >>lloc'd >>=3D=3D22324=3D=3Dat 0x1B90650D: calloc (in /usr/lib/valgrind/vgpreload_= >>memcheck.so) >>=3D=3D22324=3D=3Dby 0x81247B5: parse_expression (regex.c:5406) >>=3D=3D22324=3D=3Dby 0x8125868: parse_branch (regex.c:4475) >>=3D=3D22324=3D=3Dby 0x8125913: parse_reg_exp (regex.c:4420) >>=3D=3D22324=3D=3D=20 >>=3D=3D22324=3D=3D ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 39 f= >>rom 2) >>=3D=3D22324=3D=3D malloc/free: in use at exit: 12691882 bytes in 6426 block= >>s. >>=3D=3D22324=3D=3D malloc/free: 32534 allocs, 26108 frees, 33105500 bytes al= >>located. >>=3D=3D22324=3D=3D For a detailed leak analysis, rerun with: --leak-check= >>=3Dyes >>=3D=3D22324=3D=3D For counts of detected errors, rerun with: -v >>linux$ exit >> >>Script done on Mon 01 Aug 2005 02:10:42 PM PDT >>-- end of script -- >>--=20 >>Charles Geyer >>Professor, School of Statistics >>University of Minnesota >>[EMAIL PROTECTED] >> >>__ >>R-devel@r-project.org mailing list >>https://stat.ethz.ch/mailman/listinfo/r-devel >> >> > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] valgrind complains about regex.c (PR#8043)
Prof Brian Ripley wrote: > Did you compile R without optimization? Such reads are often the result > of read-aheads produced by the optimizer in an attempt to keep > pipelines full (and are harmless). There were both a read and a write. I can see the read being harmless, but is the write harmless? I suspect this may be the bug I fixed on July 16, since it had to do with character classes including ranges (like Charlie's "[a-pr-z]"). Charlie, have you tried a recent version of R-patched? Duncan Murdoch > > On an un-optimized build of R I am unable to reproduce this. (I also was > unable to reproduce it on my optimized build of 2.1.1 using gcc 3.4.4, > although I did get a report on other read-aheads.) > > On Mon, 1 Aug 2005 [EMAIL PROTECTED] wrote: > > >>I think I am using objects according to the man page. >>This seems to be a valid regular expression. But whether >>I know what I'm doing or no, it still shouldn't be doing >>what valgrind seems to be saying it's doing. (IMHO) > > > I think you need to take that up with compiler designers: it is common > practice. > > >>-- start of script -- >>Script started on Mon 01 Aug 2005 02:09:00 PM PDT >>linux$ printenv VALGRIND_OPTS >>--tool=3Dmemcheck >>linux$ cat bar.R >> >>foo <- 1 >>bar <- 2:3 >>baz <- 4:6 >>qux <- matrix(7:10, 2) >> >>ls() >>rm(list =3D objects(pattern =3D "^[a-pr-z]")) >>ls() >> >>linux$ R --version >>R 2.1.1 (2005-06-20). >>Copyright (C) 2005 R Development Core Team >> >>R is free software and comes with ABSOLUTELY NO WARRANTY. >>You are welcome to redistribute it under the terms of the GNU >>General Public License. For more information about these matters, >>see http://www.gnu.org/copyleft/gpl.html. >>linux$ gcc --version >>=1B[0mgcc (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux) >>=1B[0mCopyright (C) 2003 Free Software Foundation, Inc. >>=1B[0mThis is free software; see the source for copying conditions. There = >>is NO >>=1B[0mwarranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PU= >>RPOSE. >>=1B[0m >>linux$ cat /etc/SuSE-release=20 >>SuSE Linux 9.3 (i586) >>VERSION =3D 9.3 >>linux$ R --vanilla --debugger=3Dvalgrind < bar.R >| bar.Rout >>=3D=3D22324=3D=3D Memcheck, a memory error detector for x86-linux. >>=3D=3D22324=3D=3D Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward = >>et al. >>=3D=3D22324=3D=3D Using valgrind-2.2.0, a program supervision framework for= >>x86-linux. >>=3D=3D22324=3D=3D Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward = >>et al. >>=3D=3D22324=3D=3D For more details, rerun with: -v >>=3D=3D22324=3D=3D=20 >>=3D=3D22324=3D=3D Invalid read of size 4 >>=3D=3D22324=3D=3Dat 0x81255AD: parse_expression (regex.c:5045) >>=3D=3D22324=3D=3Dby 0x8125868: parse_branch (regex.c:4475) >>=3D=3D22324=3D=3Dby 0x8125913: parse_reg_exp (regex.c:4420) >>=3D=3D22324=3D=3Dby 0x81261B3: Rf_regcomp (regex.c:4384) >>=3D=3D22324=3D=3D Address 0x1C1E23A8 is 0 bytes after a block of size 32 a= >>lloc'd >>=3D=3D22324=3D=3Dat 0x1B90650D: calloc (in /usr/lib/valgrind/vgpreload_= >>memcheck.so) >>=3D=3D22324=3D=3Dby 0x81247B5: parse_expression (regex.c:5406) >>=3D=3D22324=3D=3Dby 0x8125868: parse_branch (regex.c:4475) >>=3D=3D22324=3D=3Dby 0x8125913: parse_reg_exp (regex.c:4420) >>=3D=3D22324=3D=3D=20 >>=3D=3D22324=3D=3D Invalid write of size 4 >>=3D=3D22324=3D=3Dat 0x81255B2: parse_expression (regex.c:5045) >>=3D=3D22324=3D=3Dby 0x8125868: parse_branch (regex.c:4475) >>=3D=3D22324=3D=3Dby 0x8125913: parse_reg_exp (regex.c:4420) >>=3D=3D22324=3D=3Dby 0x81261B3: Rf_regcomp (regex.c:4384) >>=3D=3D22324=3D=3D Address 0x1C1E23A8 is 0 bytes after a block of size 32 a= >>lloc'd >>=3D=3D22324=3D=3Dat 0x1B90650D: calloc (in /usr/lib/valgrind/vgpreload_= >>memcheck.so) >>=3D=3D22324=3D=3Dby 0x81247B5: parse_expression (regex.c:5406) >>=3D=3D22324=3D=3Dby 0x8125868: parse_branch (regex.c:4475) >>=3D=3D22324=3D=3Dby 0x8125913: parse_reg_exp (regex.c:4420) >>=3D=3D22324=3D=3D=20 >>=3D=3D22324=3D=3D ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 39 f= >>rom 2) >>=3D=3D22324=3D=3D malloc/free: in use at exit: 12691882 bytes in 6426 block= >>s. >>=3D=3D22324=3D=3D malloc/free: 32534 allocs, 26108 frees, 33105500 bytes al= >>located. >>=3D=3D22324=3D=3D For a detailed leak analysis, rerun with: --leak-check= >>=3Dyes >>=3D=3D22324=3D=3D For counts of detected errors, rerun with: -v >>linux$ exit >> >>Script done on Mon 01 Aug 2005 02:10:42 PM PDT >>-- end of script -- >>--=20 >>Charles Geyer >>Professor, School of Statistics >>University of Minnesota >>[EMAIL PROTECTED] >> >>__ >>R-devel@r-project.org mailing list >>https://stat.ethz.ch/mailman/listinfo/r-devel >> >> > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] valgrind complains about regex.c (PR#8043)
Yes, optimization sometimes results in writes that are apparently harmless and go away if optimization is removed. It could be the bug you found (and glibc-2.3.5 had fixed) but it isn't in exactly the right place. But then, valgrind on my system does not have a problem with that one, optimized or not. On Tue, 2 Aug 2005, Duncan Murdoch wrote: > Prof Brian Ripley wrote: >> Did you compile R without optimization? Such reads are often the result of >> read-aheads produced by the optimizer in an attempt to keep pipelines full >> (and are harmless). > > There were both a read and a write. I can see the read being harmless, but > is the write harmless? I suspect this may be the bug I fixed on July 16, > since it had to do with character classes including ranges (like Charlie's > "[a-pr-z]"). > > Charlie, have you tried a recent version of R-patched? > > Duncan Murdoch > >> >> On an un-optimized build of R I am unable to reproduce this. (I also was >> unable to reproduce it on my optimized build of 2.1.1 using gcc 3.4.4, >> although I did get a report on other read-aheads.) >> >> On Mon, 1 Aug 2005 [EMAIL PROTECTED] wrote: >> >> >>> I think I am using objects according to the man page. >>> This seems to be a valid regular expression. But whether >>> I know what I'm doing or no, it still shouldn't be doing >>> what valgrind seems to be saying it's doing. (IMHO) >> >> >> I think you need to take that up with compiler designers: it is common >> practice. >> >> >>> -- start of script -- >>> Script started on Mon 01 Aug 2005 02:09:00 PM PDT >>> linux$ printenv VALGRIND_OPTS >>> --tool=3Dmemcheck >>> linux$ cat bar.R >>> >>> foo <- 1 >>> bar <- 2:3 >>> baz <- 4:6 >>> qux <- matrix(7:10, 2) >>> >>> ls() >>> rm(list =3D objects(pattern =3D "^[a-pr-z]")) >>> ls() >>> >>> linux$ R --version >>> R 2.1.1 (2005-06-20). >>> Copyright (C) 2005 R Development Core Team >>> >>> R is free software and comes with ABSOLUTELY NO WARRANTY. >>> You are welcome to redistribute it under the terms of the GNU >>> General Public License. For more information about these matters, >>> see http://www.gnu.org/copyleft/gpl.html. >>> linux$ gcc --version >>> =1B[0mgcc (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux) >>> =1B[0mCopyright (C) 2003 Free Software Foundation, Inc. >>> =1B[0mThis is free software; see the source for copying conditions. There >>> = >>> is NO >>> =1B[0mwarranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >>> PU= >>> RPOSE. >>> =1B[0m >>> linux$ cat /etc/SuSE-release=20 >>> SuSE Linux 9.3 (i586) >>> VERSION =3D 9.3 >>> linux$ R --vanilla --debugger=3Dvalgrind < bar.R >| bar.Rout >>> =3D=3D22324=3D=3D Memcheck, a memory error detector for x86-linux. >>> =3D=3D22324=3D=3D Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward >>> = >>> et al. >>> =3D=3D22324=3D=3D Using valgrind-2.2.0, a program supervision framework >>> for= >>> x86-linux. >>> =3D=3D22324=3D=3D Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward >>> = >>> et al. >>> =3D=3D22324=3D=3D For more details, rerun with: -v >>> =3D=3D22324=3D=3D=20 >>> =3D=3D22324=3D=3D Invalid read of size 4 >>> =3D=3D22324=3D=3Dat 0x81255AD: parse_expression (regex.c:5045) >>> =3D=3D22324=3D=3Dby 0x8125868: parse_branch (regex.c:4475) >>> =3D=3D22324=3D=3Dby 0x8125913: parse_reg_exp (regex.c:4420) >>> =3D=3D22324=3D=3Dby 0x81261B3: Rf_regcomp (regex.c:4384) >>> =3D=3D22324=3D=3D Address 0x1C1E23A8 is 0 bytes after a block of size 32 >>> a= >>> lloc'd >>> =3D=3D22324=3D=3Dat 0x1B90650D: calloc (in >>> /usr/lib/valgrind/vgpreload_= >>> memcheck.so) >>> =3D=3D22324=3D=3Dby 0x81247B5: parse_expression (regex.c:5406) >>> =3D=3D22324=3D=3Dby 0x8125868: parse_branch (regex.c:4475) >>> =3D=3D22324=3D=3Dby 0x8125913: parse_reg_exp (regex.c:4420) >>> =3D=3D22324=3D=3D=20 >>> =3D=3D22324=3D=3D Invalid write of size 4 >>> =3D=3D22324=3D=3Dat 0x81255B2: parse_expression (regex.c:5045) >>> =3D=3D22324=3D=3Dby 0x8125868: parse_branch (regex.c:4475) >>> =3D=3D22324=3D=3Dby 0x8125913: parse_reg_exp (regex.c:4420) >>> =3D=3D22324=3D=3Dby 0x81261B3: Rf_regcomp (regex.c:4384) >>> =3D=3D22324=3D=3D Address 0x1C1E23A8 is 0 bytes after a block of size 32 >>> a= >>> lloc'd >>> =3D=3D22324=3D=3Dat 0x1B90650D: calloc (in >>> /usr/lib/valgrind/vgpreload_= >>> memcheck.so) >>> =3D=3D22324=3D=3Dby 0x81247B5: parse_expression (regex.c:5406) >>> =3D=3D22324=3D=3Dby 0x8125868: parse_branch (regex.c:4475) >>> =3D=3D22324=3D=3Dby 0x8125913: parse_reg_exp (regex.c:4420) >>> =3D=3D22324=3D=3D=20 >>> =3D=3D22324=3D=3D ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 39 >>> f= >>> rom 2) >>> =3D=3D22324=3D=3D malloc/free: in use at exit: 12691882 bytes in 6426 >>> block= >>> s. >>> =3D=3D22324=3D=3D malloc/free: 32534 allocs, 26108 frees, 33105500 bytes >>> al= >>> located. >>> =3D=3D22324=3D=3D For a detailed leak analysis, rerun with: --leak-check= >>> =3Dyes >>> =3
Re: [Rd] valgrind complains about regex.c (PR#8043)
On Tue, Aug 02, 2005 at 07:50:54AM -0400, Duncan Murdoch wrote: > Prof Brian Ripley wrote: > >Did you compile R without optimization? Such reads are often the result > >of read-aheads produced by the optimizer in an attempt to keep > >pipelines full (and are harmless). > > There were both a read and a write. I can see the read being harmless, > but is the write harmless? I suspect this may be the bug I fixed on > July 16, since it had to do with character classes including ranges > (like Charlie's "[a-pr-z]"). > > Charlie, have you tried a recent version of R-patched? No. And I can't do it right away. I'm packing up to move back to Minneapolis after my sabbatical year in Seattle. Maybe in a few days. Sorry to not be more helpful. Maybe I'll try it on the plane if I can. > Duncan Murdoch > > > > >On an un-optimized build of R I am unable to reproduce this. (I also was > >unable to reproduce it on my optimized build of 2.1.1 using gcc 3.4.4, > >although I did get a report on other read-aheads.) > > > >On Mon, 1 Aug 2005 [EMAIL PROTECTED] wrote: > > > > > >>I think I am using objects according to the man page. > >>This seems to be a valid regular expression. But whether > >>I know what I'm doing or no, it still shouldn't be doing > >>what valgrind seems to be saying it's doing. (IMHO) > > > > > >I think you need to take that up with compiler designers: it is common > >practice. > > > > > >>-- start of script -- > >>Script started on Mon 01 Aug 2005 02:09:00 PM PDT > >>linux$ printenv VALGRIND_OPTS > >>--tool=3Dmemcheck > >>linux$ cat bar.R > >> > >>foo <- 1 > >>bar <- 2:3 > >>baz <- 4:6 > >>qux <- matrix(7:10, 2) > >> > >>ls() > >>rm(list =3D objects(pattern =3D "^[a-pr-z]")) > >>ls() > >> > >>linux$ R --version > >>R 2.1.1 (2005-06-20). > >>Copyright (C) 2005 R Development Core Team > >> > >>R is free software and comes with ABSOLUTELY NO WARRANTY. > >>You are welcome to redistribute it under the terms of the GNU > >>General Public License. For more information about these matters, > >>see http://www.gnu.org/copyleft/gpl.html. > >>linux$ gcc --version > >>=1B[0mgcc (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux) > >>=1B[0mCopyright (C) 2003 Free Software Foundation, Inc. > >>=1B[0mThis is free software; see the source for copying conditions. > >>There = > >>is NO > >>=1B[0mwarranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > >>PU= > >>RPOSE. > >>=1B[0m > >>linux$ cat /etc/SuSE-release=20 > >>SuSE Linux 9.3 (i586) > >>VERSION =3D 9.3 > >>linux$ R --vanilla --debugger=3Dvalgrind < bar.R >| bar.Rout > >>=3D=3D22324=3D=3D Memcheck, a memory error detector for x86-linux. > >>=3D=3D22324=3D=3D Copyright (C) 2002-2004, and GNU GPL'd, by Julian > >>Seward = > >>et al. > >>=3D=3D22324=3D=3D Using valgrind-2.2.0, a program supervision framework > >>for= > >>x86-linux. > >>=3D=3D22324=3D=3D Copyright (C) 2000-2004, and GNU GPL'd, by Julian > >>Seward = > >>et al. > >>=3D=3D22324=3D=3D For more details, rerun with: -v > >>=3D=3D22324=3D=3D=20 > >>=3D=3D22324=3D=3D Invalid read of size 4 > >>=3D=3D22324=3D=3Dat 0x81255AD: parse_expression (regex.c:5045) > >>=3D=3D22324=3D=3Dby 0x8125868: parse_branch (regex.c:4475) > >>=3D=3D22324=3D=3Dby 0x8125913: parse_reg_exp (regex.c:4420) > >>=3D=3D22324=3D=3Dby 0x81261B3: Rf_regcomp (regex.c:4384) > >>=3D=3D22324=3D=3D Address 0x1C1E23A8 is 0 bytes after a block of size 32 > >>a= > >>lloc'd > >>=3D=3D22324=3D=3Dat 0x1B90650D: calloc (in > >>/usr/lib/valgrind/vgpreload_= > >>memcheck.so) > >>=3D=3D22324=3D=3Dby 0x81247B5: parse_expression (regex.c:5406) > >>=3D=3D22324=3D=3Dby 0x8125868: parse_branch (regex.c:4475) > >>=3D=3D22324=3D=3Dby 0x8125913: parse_reg_exp (regex.c:4420) > >>=3D=3D22324=3D=3D=20 > >>=3D=3D22324=3D=3D Invalid write of size 4 > >>=3D=3D22324=3D=3Dat 0x81255B2: parse_expression (regex.c:5045) > >>=3D=3D22324=3D=3Dby 0x8125868: parse_branch (regex.c:4475) > >>=3D=3D22324=3D=3Dby 0x8125913: parse_reg_exp (regex.c:4420) > >>=3D=3D22324=3D=3Dby 0x81261B3: Rf_regcomp (regex.c:4384) > >>=3D=3D22324=3D=3D Address 0x1C1E23A8 is 0 bytes after a block of size 32 > >>a= > >>lloc'd > >>=3D=3D22324=3D=3Dat 0x1B90650D: calloc (in > >>/usr/lib/valgrind/vgpreload_= > >>memcheck.so) > >>=3D=3D22324=3D=3Dby 0x81247B5: parse_expression (regex.c:5406) > >>=3D=3D22324=3D=3Dby 0x8125868: parse_branch (regex.c:4475) > >>=3D=3D22324=3D=3Dby 0x8125913: parse_reg_exp (regex.c:4420) > >>=3D=3D22324=3D=3D=20 > >>=3D=3D22324=3D=3D ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 39 > >>f= > >>rom 2) > >>=3D=3D22324=3D=3D malloc/free: in use at exit: 12691882 bytes in 6426 > >>block= > >>s. > >>=3D=3D22324=3D=3D malloc/free: 32534 allocs, 26108 frees, 33105500 bytes > >>al= > >>located. > >>=3D=3D22324=3D=3D For a detailed leak analysis, rerun with: --leak-check= > >>=3Dyes > >>=3D=3D22324=3D=3D For counts of detected errors, rerun with: -v > >>linux$ ex
Re: [Rd] valgrind complains about regex.c (PR#8043)
On Tue, Aug 02, 2005 at 07:50:54AM -0400, Duncan Murdoch wrote: > Prof Brian Ripley wrote: > >Did you compile R without optimization? Such reads are often the result > >of read-aheads produced by the optimizer in an attempt to keep > >pipelines full (and are harmless). > > There were both a read and a write. I can see the read being harmless, > but is the write harmless? I suspect this may be the bug I fixed on > July 16, since it had to do with character classes including ranges > (like Charlie's "[a-pr-z]"). > > Charlie, have you tried a recent version of R-patched? No. And I can't do it right away. I'm packing up to move back to Minneapolis after my sabbatical year in Seattle. Maybe in a few days. Sorry to not be more helpful. Maybe I'll try it on the plane if I can. > Duncan Murdoch > > > > >On an un-optimized build of R I am unable to reproduce this. (I also was > >unable to reproduce it on my optimized build of 2.1.1 using gcc 3.4.4, > >although I did get a report on other read-aheads.) > > > >On Mon, 1 Aug 2005 [EMAIL PROTECTED] wrote: > > > > > >>I think I am using objects according to the man page. > >>This seems to be a valid regular expression. But whether > >>I know what I'm doing or no, it still shouldn't be doing > >>what valgrind seems to be saying it's doing. (IMHO) > > > > > >I think you need to take that up with compiler designers: it is common > >practice. > > > > > >>-- start of script -- > >>Script started on Mon 01 Aug 2005 02:09:00 PM PDT > >>linux$ printenv VALGRIND_OPTS > >>--tool=3Dmemcheck > >>linux$ cat bar.R > >> > >>foo <- 1 > >>bar <- 2:3 > >>baz <- 4:6 > >>qux <- matrix(7:10, 2) > >> > >>ls() > >>rm(list =3D objects(pattern =3D "^[a-pr-z]")) > >>ls() > >> > >>linux$ R --version > >>R 2.1.1 (2005-06-20). > >>Copyright (C) 2005 R Development Core Team > >> > >>R is free software and comes with ABSOLUTELY NO WARRANTY. > >>You are welcome to redistribute it under the terms of the GNU > >>General Public License. For more information about these matters, > >>see http://www.gnu.org/copyleft/gpl.html. > >>linux$ gcc --version > >>=1B[0mgcc (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux) > >>=1B[0mCopyright (C) 2003 Free Software Foundation, Inc. > >>=1B[0mThis is free software; see the source for copying conditions. > >>There = > >>is NO > >>=1B[0mwarranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > >>PU= > >>RPOSE. > >>=1B[0m > >>linux$ cat /etc/SuSE-release=20 > >>SuSE Linux 9.3 (i586) > >>VERSION =3D 9.3 > >>linux$ R --vanilla --debugger=3Dvalgrind < bar.R >| bar.Rout > >>=3D=3D22324=3D=3D Memcheck, a memory error detector for x86-linux. > >>=3D=3D22324=3D=3D Copyright (C) 2002-2004, and GNU GPL'd, by Julian > >>Seward = > >>et al. > >>=3D=3D22324=3D=3D Using valgrind-2.2.0, a program supervision framework > >>for= > >>x86-linux. > >>=3D=3D22324=3D=3D Copyright (C) 2000-2004, and GNU GPL'd, by Julian > >>Seward = > >>et al. > >>=3D=3D22324=3D=3D For more details, rerun with: -v > >>=3D=3D22324=3D=3D=20 > >>=3D=3D22324=3D=3D Invalid read of size 4 > >>=3D=3D22324=3D=3Dat 0x81255AD: parse_expression (regex.c:5045) > >>=3D=3D22324=3D=3Dby 0x8125868: parse_branch (regex.c:4475) > >>=3D=3D22324=3D=3Dby 0x8125913: parse_reg_exp (regex.c:4420) > >>=3D=3D22324=3D=3Dby 0x81261B3: Rf_regcomp (regex.c:4384) > >>=3D=3D22324=3D=3D Address 0x1C1E23A8 is 0 bytes after a block of size 32 > >>a= > >>lloc'd > >>=3D=3D22324=3D=3Dat 0x1B90650D: calloc (in > >>/usr/lib/valgrind/vgpreload_= > >>memcheck.so) > >>=3D=3D22324=3D=3Dby 0x81247B5: parse_expression (regex.c:5406) > >>=3D=3D22324=3D=3Dby 0x8125868: parse_branch (regex.c:4475) > >>=3D=3D22324=3D=3Dby 0x8125913: parse_reg_exp (regex.c:4420) > >>=3D=3D22324=3D=3D=20 > >>=3D=3D22324=3D=3D Invalid write of size 4 > >>=3D=3D22324=3D=3Dat 0x81255B2: parse_expression (regex.c:5045) > >>=3D=3D22324=3D=3Dby 0x8125868: parse_branch (regex.c:4475) > >>=3D=3D22324=3D=3Dby 0x8125913: parse_reg_exp (regex.c:4420) > >>=3D=3D22324=3D=3Dby 0x81261B3: Rf_regcomp (regex.c:4384) > >>=3D=3D22324=3D=3D Address 0x1C1E23A8 is 0 bytes after a block of size 32 > >>a= > >>lloc'd > >>=3D=3D22324=3D=3Dat 0x1B90650D: calloc (in > >>/usr/lib/valgrind/vgpreload_= > >>memcheck.so) > >>=3D=3D22324=3D=3Dby 0x81247B5: parse_expression (regex.c:5406) > >>=3D=3D22324=3D=3Dby 0x8125868: parse_branch (regex.c:4475) > >>=3D=3D22324=3D=3Dby 0x8125913: parse_reg_exp (regex.c:4420) > >>=3D=3D22324=3D=3D=20 > >>=3D=3D22324=3D=3D ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 39 > >>f= > >>rom 2) > >>=3D=3D22324=3D=3D malloc/free: in use at exit: 12691882 bytes in 6426 > >>block= > >>s. > >>=3D=3D22324=3D=3D malloc/free: 32534 allocs, 26108 frees, 33105500 bytes > >>al= > >>located. > >>=3D=3D22324=3D=3D For a detailed leak analysis, rerun with: --leak-check= > >>=3Dyes > >>=3D=3D22324=3D=3D For counts of detected errors, rerun with: -v > >>linux$ ex
Re: [Rd] valgrind complains about regex.c (PR#8043)
On Tue, Aug 02, 2005 at 07:13:54AM +0100, Prof Brian Ripley wrote: > Did you compile R without optimization? Such reads are often the result > of read-aheads produced by the optimizer in an attempt to keep > pipelines full (and are harmless). linux$ R CMD config CFLAGS -g -O2 so no. I just took the defaults. I'll try that too along with R-patched. > > On an un-optimized build of R I am unable to reproduce this. (I also was > unable to reproduce it on my optimized build of 2.1.1 using gcc 3.4.4, > although I did get a report on other read-aheads.) > > On Mon, 1 Aug 2005 [EMAIL PROTECTED] wrote: > > >I think I am using objects according to the man page. > >This seems to be a valid regular expression. But whether > >I know what I'm doing or no, it still shouldn't be doing > >what valgrind seems to be saying it's doing. (IMHO) > > I think you need to take that up with compiler designers: it is common > practice. > > >-- start of script -- > >Script started on Mon 01 Aug 2005 02:09:00 PM PDT > >linux$ printenv VALGRIND_OPTS > >--tool=3Dmemcheck > >linux$ cat bar.R > > > >foo <- 1 > >bar <- 2:3 > >baz <- 4:6 > >qux <- matrix(7:10, 2) > > > >ls() > >rm(list =3D objects(pattern =3D "^[a-pr-z]")) > >ls() > > > >linux$ R --version > >R 2.1.1 (2005-06-20). > >Copyright (C) 2005 R Development Core Team > > > >R is free software and comes with ABSOLUTELY NO WARRANTY. > >You are welcome to redistribute it under the terms of the GNU > >General Public License. For more information about these matters, > >see http://www.gnu.org/copyleft/gpl.html. > >linux$ gcc --version > >=1B[0mgcc (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux) > >=1B[0mCopyright (C) 2003 Free Software Foundation, Inc. > >=1B[0mThis is free software; see the source for copying conditions. There > >= > >is NO > >=1B[0mwarranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > >PU= > >RPOSE. > >=1B[0m > >linux$ cat /etc/SuSE-release=20 > >SuSE Linux 9.3 (i586) > >VERSION =3D 9.3 > >linux$ R --vanilla --debugger=3Dvalgrind < bar.R >| bar.Rout > >=3D=3D22324=3D=3D Memcheck, a memory error detector for x86-linux. > >=3D=3D22324=3D=3D Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward > >= > >et al. > >=3D=3D22324=3D=3D Using valgrind-2.2.0, a program supervision framework > >for= > >x86-linux. > >=3D=3D22324=3D=3D Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward > >= > >et al. > >=3D=3D22324=3D=3D For more details, rerun with: -v > >=3D=3D22324=3D=3D=20 > >=3D=3D22324=3D=3D Invalid read of size 4 > >=3D=3D22324=3D=3Dat 0x81255AD: parse_expression (regex.c:5045) > >=3D=3D22324=3D=3Dby 0x8125868: parse_branch (regex.c:4475) > >=3D=3D22324=3D=3Dby 0x8125913: parse_reg_exp (regex.c:4420) > >=3D=3D22324=3D=3Dby 0x81261B3: Rf_regcomp (regex.c:4384) > >=3D=3D22324=3D=3D Address 0x1C1E23A8 is 0 bytes after a block of size 32 > >a= > >lloc'd > >=3D=3D22324=3D=3Dat 0x1B90650D: calloc (in > >/usr/lib/valgrind/vgpreload_= > >memcheck.so) > >=3D=3D22324=3D=3Dby 0x81247B5: parse_expression (regex.c:5406) > >=3D=3D22324=3D=3Dby 0x8125868: parse_branch (regex.c:4475) > >=3D=3D22324=3D=3Dby 0x8125913: parse_reg_exp (regex.c:4420) > >=3D=3D22324=3D=3D=20 > >=3D=3D22324=3D=3D Invalid write of size 4 > >=3D=3D22324=3D=3Dat 0x81255B2: parse_expression (regex.c:5045) > >=3D=3D22324=3D=3Dby 0x8125868: parse_branch (regex.c:4475) > >=3D=3D22324=3D=3Dby 0x8125913: parse_reg_exp (regex.c:4420) > >=3D=3D22324=3D=3Dby 0x81261B3: Rf_regcomp (regex.c:4384) > >=3D=3D22324=3D=3D Address 0x1C1E23A8 is 0 bytes after a block of size 32 > >a= > >lloc'd > >=3D=3D22324=3D=3Dat 0x1B90650D: calloc (in > >/usr/lib/valgrind/vgpreload_= > >memcheck.so) > >=3D=3D22324=3D=3Dby 0x81247B5: parse_expression (regex.c:5406) > >=3D=3D22324=3D=3Dby 0x8125868: parse_branch (regex.c:4475) > >=3D=3D22324=3D=3Dby 0x8125913: parse_reg_exp (regex.c:4420) > >=3D=3D22324=3D=3D=20 > >=3D=3D22324=3D=3D ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 39 > >f= > >rom 2) > >=3D=3D22324=3D=3D malloc/free: in use at exit: 12691882 bytes in 6426 > >block= > >s. > >=3D=3D22324=3D=3D malloc/free: 32534 allocs, 26108 frees, 33105500 bytes > >al= > >located. > >=3D=3D22324=3D=3D For a detailed leak analysis, rerun with: --leak-check= > >=3Dyes > >=3D=3D22324=3D=3D For counts of detected errors, rerun with: -v > >linux$ exit > > > >Script done on Mon 01 Aug 2005 02:10:42 PM PDT > >-- end of script -- > >--=20 > >Charles Geyer > >Professor, School of Statistics > >University of Minnesota > >[EMAIL PROTECTED] > > > >__ > >R-devel@r-project.org mailing list > >https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > -- > 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 R
Re: [Rd] Follow-Up: R on FC4
Peter Dalgaard <[EMAIL PROTECTED]> writes:
> Gavin Simpson <[EMAIL PROTECTED]> writes:
> > So far so good with FC4, gcc4, gfortran and R!
>
> The problem affecting the Fedora Extras RPM is still there with the
> new compilers though:
>
> -Wp,-D_FORTIFY_SOURCE=2
>
> combined with -O or -O2 causes a strange printing bug:
>
> > matrix(list(pi))
> [,1]
> [1,]
>
> (You don't have to use that option of course, but it suggests that not
> all is well with the optimizer. And the Fedora maintainer seem set on
> using it, which is a bit of a problem.)
I'm fairly sure by now that this is actually a bug in R, not gcc. We
have the same internal buffer structure used in EncodeReal and in
Rsprintf, and the return value of the former is buffer->data
which is reallocated by the latter.
That means that constructions of the form
pbuf = Rsprintf("%s", EncodeReal(REAL(tmp)[0], w, d, e, OutDec));
are playing with fire. There are quite a few other similar
constructions involving Encode*.
I suspect is is necessary to copy the result of
EncodeReal(REAL(tmp)[0], w, d, e, OutDec) to temp storage, or -
probably easier - use a separate buffer for Rsprintf.
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] possibility of R/Maxima linking
Hello, I'm aware that recently there has been discussion of R joining forces with an algebra system in some way. Here is my $0.02. I suggest linking R with Maxima (http://maxima.sf.net). Maxima is written in Lisp. Maxima objects are pretty simple. Maxima works on expressions, and almost every expression is a Lisp list of the form ((op) arg1 arg2 arg3 ...) which associates an operator and its arguments. Every kind of operation is cast in this form -- infix, prefix, postfix, function calls, array references, lists, and even control structures such as if-then-else and do-loops. Maxima usually parses an input written in the Maxima language (yet another Algol derivative) and then calls MEVAL, the main evaluation function, with the Lisp representation of the input as its argument. However, if R could construct a suitable Lisp object, R could bypass the parsing and just call MEVAL directly. Although several interfaces which are based on sockets have been created, I believe it should be possible to directly link Maxima with R, if Maxima is compiled with a Lisp variety which is implemented in C. I believe direct linkage is possible with Clisp, and maybe with GCL as well. Whether or not this scheme works depends pretty strongly on how much effort is needed to munge R objects into Lisp. Maybe someone has some comments about that. There is more that can be said but I'll let this be enough for now. all the best, Robert Dodier __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
