Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crashes reported on bioc-devel #52

Closed
lgatto opened this issue Sep 22, 2016 · 6 comments
Closed

Crashes reported on bioc-devel #52

lgatto opened this issue Sep 22, 2016 · 6 comments

Comments

@lgatto
Copy link
Collaborator

lgatto commented Sep 22, 2016

From [Bioc-devel] msPurity build fail on Mac OS X (morelia), @mtmorgan offers the following patch.

Index: src/cramp.cpp
===================================================================
--- src/cramp.cpp   (revision 121179)
+++ src/cramp.cpp   (working copy)
@@ -95,7 +95,7 @@
          //      if (m_runInfo->m_data.scanCount < 0) { // undeclared 
scan count
          // this will provoke reading of index, which sets scan count
          rampScanInfo* tmp = getScanHeaderInfo ( 1 );
-        free(tmp);
+        delete(tmp);
          // }
          // END HENRY
      }

It's not clear to me yet if this is really the reason for the reported problem, so I haven't applied it yet. I will once we get to the bottom of the msPurity problem.

@lgatto lgatto added the bug label Sep 22, 2016
@mtmorgan
Copy link

I'd guess that there were many of these new / delete mismatches, and a little tedious to track down!

@lgatto
Copy link
Collaborator Author

lgatto commented Sep 22, 2016

Are all free calls to be replaced by delete, or only some?

@mtmorgan
Copy link

If the memory is allocated by new(), then it needs to be deleteed; if it's allocated by malloc(), then free().

@lgatto lgatto added the patch label Sep 22, 2016
lgatto pushed a commit that referenced this issue Sep 22, 2016
@jorainer
Copy link
Collaborator

These new-delete and malloc-free calls are pretty difficult to track in the code. I've tried that for some time as I was suspecting that these might cause some of the random errors we've got earlier (e.g. lgatto/MSnbase#138).

@jorainer
Copy link
Collaborator

do you know of an automated or semi-automated way to check for similar problems in the code? Otherwise it might be quite a task to search for them.

@lgatto
Copy link
Collaborator Author

lgatto commented Sep 22, 2016

Some file (like cramp.*, ramp.*) are very unlikely to change. pwiz changes should ideally be discussed and pushed upstream.

@lgatto lgatto closed this as completed Dec 9, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants