[Rcpp-devel] simple Rcpp function produces: "AddressSanitizer: attempting free on address which was not malloc"

Smith, Dale (Norcross) Dale.Smith at Fiserv.com
Tue Jul 9 13:35:15 CEST 2013


My $0.02.



Dirk is right - pick something and stick with it, but avoid the raw pointers, especially if your experience is limited. It's much easier to learn the smart pointers std::shared_ptr and std::unique_ptr, or their boost equivalents, rather than deal with raw pointers in new code.


http://www.codeproject.com/Articles/541067/Cplusplus11-Smart-Pointers



std::vector is your friend; learn to use it. Just allocate enough space with resize, use operator(...)[] to access/set the elements of the vector (do not use .push_back as this appends to the end of the vector) and you will not suffer the overhead of extending the size of the vector (some implementations copy the entire vector).



http://www.codeproject.com/Articles/5378/A-Presentation-of-the-STL-Vector-Container


"After reading this article, the reader should be able to use the vector container effectively and should find no use for dynamic C-style arrays again." In fact, you should learn the Standard Template Library very well as the algorithms and containers it implements are highly optimized and very efficient.



I have made good use of Armadillo, have avoided any explicit memory allocation at all, and even append columns to matrices when necessary.



Dale Smith, Ph.D.

Senior Financial Quantitative Analyst

Risk & Compliance

Fiserv

Office: 678-375-5315

www.fiserv.com



-----Original Message-----
From: rcpp-devel-bounces at r-forge.wu-wien.ac.at [mailto:rcpp-devel-bounces at r-forge.wu-wien.ac.at] On Behalf Of Dirk Eddelbuettel
Sent: Tuesday, July 09, 2013 2:46 AM
To: Darren Cook
Cc: rcpp-devel at r-forge.wu-wien.ac.at
Subject: Re: [Rcpp-devel] simple Rcpp function produces: "AddressSanitizer: attempting free on address which was not malloc"





On 9 July 2013 at 11:42, Darren Cook wrote:

| > The C++ function, though, is quite simple -- I wonder if anyone

| > might be able to spot easily what is going on?

| > ...

| >     double Cnm;

| >     Cnm = nChoosek(*n, *m);

| >     ...

| >     int* combmat;

| >     combmat = new int[(int)Cnm**(m+0)];

|

| I'm not sure if this is the cause of the complaint, but in a code

| review I'd have red flags all over that last line:

|

|   * Cnm is a double, but you truncate it to an int.

|     Rounding *down* to then do a memory allocation makes me nervous.

|     If Cnm is only ever an integer, keep it as int and cast the return

| value from nChoosek() instead.

|     (You also do the same cast to int ncols later on.)

|

|   * Can  *(m+0) be rewritten as *m ?

|

|   * I assume it should read:   Cnm * nrows

|     where nrows is *m?

|     Very minor but ** also means double dereference, so I'd like at

| least a space to make the intention clear.



Adding to this:



    * you use 'new' to allocatate space, but DO NOT call delete -- memory leak.



In short, these days you almost never ever have a reason to use malloc/free or new/delete. Ever.  Learn more about STL vectors, and use those.

Safer. Easier. Better.



Pick one representation: arma, or Rcpp, or STL vectors. Stick with it.  Maybe develop your core computation in a standalone program on fixed data. The connect to R.



Hth,  Dirk



|

| Darren

|

| _______________________________________________

| Rcpp-devel mailing list

| Rcpp-devel at lists.r-forge.r-project.org<mailto:Rcpp-devel at lists.r-forge.r-project.org>

| https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-deve

| l



--

Dirk Eddelbuettel | edd at debian.org<mailto:edd at debian.org> | http://dirk.eddelbuettel.com _______________________________________________

Rcpp-devel mailing list

Rcpp-devel at lists.r-forge.r-project.org<mailto:Rcpp-devel at lists.r-forge.r-project.org>

https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20130709/f7541f93/attachment.html>


More information about the Rcpp-devel mailing list