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
RDF.__init__ SEGFAULT #32
Comments
Original comment by Joshua Anderson (Bitbucket: joaander, GitHub: joaander). I've got a more reliable reproducer now. I get the issue with python 3.4.1 (tested 3.4.2 as well). But I do not get the issue with 2.7. Who all is affected by this issue? Is it just on the vis lab machines? |
Original comment by Carl Simon Adorf (Bitbucket: csadorf, GitHub: csadorf). This is Richmond's test case.
|
Original comment by Joshua Anderson (Bitbucket: joaander, GitHub: joaander). Here is the backtrace:
The minimum ingredients needed appear to be python + boost + calling a function that takes a boost::python::numeric::array input. |
Original comment by Richmond Newman (Bitbucket: newmanr, GitHub: newmanr). My new iMac (gatesbrown, OSX yosemite, python 3.4.2) is afflicted with segfaults when using freud too. If you ensure that any used freud module is either reused, or kept in memory until the end of the script, your work will at least complete before segfaulting on exit. Not a real fix of course, just a way to live with it temporarily. I tried creating a boost python example test program, (entirely independent of freud) and get the same errors. I cannot safely deallocate a class after a call to one of its member functions passing in a boost::python::numeric array (even if said function is empty and does nothing with it). So I guess that's the same as Josh's findings. Simon: When you can't get it to crash in gdb, did you test a few times? I found that I couldn't get scripts to crash within GDB, but they would segfault (stochastically but with moderate probability) upon exiting. I tried creating an example outside of freud as well, but the results remained the same. Calling a function that takes in a boost::python::nuermic::array, even a function that does nothing will trigger the problem. If the module you're using is never deallocated, then |
Original comment by Richmond Newman (Bitbucket: newmanr, GitHub: newmanr).
I did manage, however, to write one script that I can't seem to segfault on my iMac, included above. Herein I throw all the created objects into a giant list, which normally would segfault on deallocation at the end of the script. However, if you set some debug parameters to the garbage collector, this seems to prevent that from happening. However, regardless of when this parameter is set (beginning or end), if objects are destroyed during the script, it will still segfault. Sigh. |
Original comment by Carl Simon Adorf (Bitbucket: csadorf, GitHub: csadorf). Hi, when I tested with GDB I was not aware of the stochastic nature of the problem. So I am pretty sure the problem would occur eventually. One quick word of warning: I proposed this pointer array to prevent deallocation as a quick test to pinpoint the source of error. We should definitely not use it as a workaround in any kind of productive environment as it presents a massive memory leak. |
Original comment by Richmond Newman (Bitbucket: newmanr, GitHub: newmanr). Giant memory leak indeed. Most of the modules I use for production runs reuse, so they (far as I know) aren't afflicted by the problem w/ being deallocated in the middle of the script. I'm honestly not sure though what to do to fix these errors, since it seems to exist outside the scope of our code. |
Original comment by Joshua Anderson (Bitbucket: joaander, GitHub: joaander). OK, my minimal example is much more minimal:
I commented out any code that would actually do anything in compute() in LocalDensity. Then I ran this test:
This segfaults on petry 3 out of every 4 runs with the backtrace I posted above. If I change My conclusion is that the problem is somehow caused in garbage collecting a numpy array that has been touched by Searching by keywords on the line of code at In any case, this appears to be either a python or boost (or the way the interact) bug and not how we are using them in freud. I am going to roll the linux boxes back to python 3.3. That is the quickest way to work around the problem for now. I certainly don't have the time to try and track down subtle memory manager issues in python far enough to submit a bug. |
Original report by Carl Simon Adorf (Bitbucket: csadorf, GitHub: csadorf).
I'm currently porting my scripts to python3.4 on collins when I encountered this bug.
The bug occurs when I try to calculate the RDF from a previously read XMLDCDTrajectory.
The text was updated successfully, but these errors were encountered: