Re: [julia-users] Re: Double free or corruption (out)

So it looks like I'm having the same issue - have been running the code without parallelization (defining my SharedArrays as regular ones), and it has now been going for about 3 days without any segfaults. Is this a known issue? If so, do we know whether there's a Julia version one can revert

Re: [julia-users] Re: Double free or corruption (out)

Hm, interesting observation... I suppose the issue in my case is that the code as it is takes about 3-4 days to complete, so running it on 1 instead of 15 cores means I'm unlikely to ever get my PhD! I will at least try to run a shorter version that might be solvable in a day or two without

Re: [julia-users] Re: Double free or corruption (out)

Have you tried running the code without using parallel? I have been getting similar errors in my economics code. It segfaults sometimes, though not always, after a seemingly random amount of time, sometimes an hour or so, sometimes less. However, I don't recall it having ever occurred in the

Re: [julia-users] Re: Double free or corruption (out)

Fair enough. Does anyone have any clues as to how I would go about investigating this? As has been said before, the stacktraces aren't very helpful for segfaults, so how do I figure out what's going wrong here?

Re: [julia-users] Re: Double free or corruption (out)

I've checked that the problem we were having doesn't happen with Julia 0.4.5 on Travis. In fact, it also doesn't happen on another one of our systems with Julia 0.4.5, so at this stage we have no idea what the problem is. It may be totally unrelated to the problem you are having. Bill. On 31 May

Re: [julia-users] Re: Double free or corruption (out)

We are also suddenly getting crashes with 2.4.5. when running our (Nemo) test suite. It says that some memory allocation is failing due to invalid next size. I suspect there is a bug that wasn't there until the last few days, since we were passing just fine on Travis. Though at this stage, I

Re: [julia-users] Re: Double free or corruption (out)

Resurrecting this very old thread - after having been able to solve the model with no seg faults over the last couple of months, they have now returned and occur much faster (usually within 2 hours of running the code). I have refactored the code a little so that it hopefully will be possible

Re: [julia-users] Re: Double free or corruption (out)

On Sat, Sep 26, 2015 at 1:07 PM, Nils Gudat wrote: > That's the problem I alluded to in my question: This happened in the middle > of a very lengthy minimization problem, which had been running for a couple > of hours. On a previous run, a very similar version of the code

[julia-users] Re: Double free or corruption (out)

The malloc/free functions are the ones that allocate and free blocks of memory. They are provided by the system (e.g. Linux). A double free or corruption likely means that free was called twice on the same block of memory, or that something was overwritten that shouldn't have been, e.g. an

Re: [julia-users] Re: Double free or corruption (out)

The minimization itself is NLopt, the problem is to solve an economic model (which takes around 2 minutes to solve on 16 cores) and compare its output (a 100x4 Float64 Array) to some data moments. The model results depend on two parameters. The model itself is mostly minimization (via Optim)

Re: [julia-users] Re: Double free or corruption (out)

On Sat, Sep 26, 2015 at 2:37 PM, Nils Gudat wrote: > The minimization itself is NLopt, the problem is to solve an economic model > (which takes around 2 minutes to solve on 16 cores) and compare its output > (a 100x4 Float64 Array) to some data moments. The model results

Re: [julia-users] Re: Double free or corruption (out)

> Looks like there's at least one segfault in NLopt (AppVeyor Nightly > Win32) and I can reproduce locally with aggressive GC. Will > investigate. Fixed in https://github.com/JuliaLang/julia/pull/13325 I have no idea if it is the same SegFault/corruption you are seeing or on the AppVeyor

[julia-users] Re: Double free or corruption (out)

That's the problem I alluded to in my question: This happened in the middle of a very lengthy minimization problem, which had been running for a couple of hours. On a previous run, a very similar version of the code finished successfully after about 10 hours. I was hoping that someone could at