Hi Simon,
I can reproduce both issues, and the issues are as follows.
1) BeagleOperation should be declared as `immutable`. If not, then the
BeagleOperation objects are not inlined into the temporary array, so you
are effectively passing (in C) `{ BeagleOperation*, BeagleOperation* }`
when what you need is BeagleOperation[2].
Having struggled to explain this (and confused myself in the process)
multiple times, I'll be the first to admit that our documentation has been
lacking on this point. Fortunately in the "latest" branch of the docs
Jameson has made some very nice improvements:
http://docs.julialang.org/en/latest/manual/calling-c-and-fortran-code/#struct-type-correspondences
2) The segfault you mentioned in `beagleCalculateRootLogLikelihoods`: this
one was a head-scratcher (oh good, autotools lacks a default debug target.
no one would ever want that! but I digress). It turns out that the call to
`beagleSetStateFrequencies` (
https://gist.github.com/sdwfrost/5c574857bd91648fb7ee#file-beagle-jl-L103)
is missing a parameter, so the internal variable `gStateFrequences` is not
properly initialized, thus an attempt to dereference a too-small array at
`BeagleCPU4StateImpl.hpp:420` causes the segfault. Changing the signature
to:
ccall((:beagleSetStateFrequencies, "libhmsbeagle"),
Int,
(Cint,Cint,Ptr{Cdouble}),
instance,0,freqs)
Fixes the problem. I can't say myself if the results are accurate, but
the script now runs segfault-free!
Best,
Isaiah
On Sat, Apr 18, 2015 at 9:58 AM, Simon Frost <[email protected]> wrote:
> Dear Isaiah,
>
> Thanks! I've put my code here:
>
> https://gist.github.com/sdwfrost/5c574857bd91648fb7ee
>
> The code currently dies here:
>
> operations = [
> BeagleOperation(3, BEAGLE_OP_NONE, BEAGLE_OP_NONE, 0, 0, 1, 1),
> BeagleOperation(4, BEAGLE_OP_NONE, BEAGLE_OP_NONE, 2, 2, 3, 3)
> ]
>
> ccall((:beagleUpdatePartials, "libhmsbeagle"),
> Int,
> (Cint,Ptr{BeagleOperation},Cint,Cint),
> instance,operations,2,BEAGLE_OP_NONE)
>
> I've tried various things to pass an array of structs as a pointer, but
> nothing avoids a segfault.
>
> Best
> Simon
>
> On Saturday, April 18, 2015 at 2:29:14 PM UTC+1, Isaiah wrote:
>>
>> Hi Simon,
>>
>> Is the use of an array here ... a way round converting things to
>>> pointers?
>>
>>
>> Yes, see:
>>
>> http://docs.julialang.org/en/release-0.3/manual/calling-c-and-fortran-code/#passing-pointers-for-modifying-inputs
>>
>> (you could do `retInfo = BeagleInstanceDetails(...)` and then pass
>> `&retInfo` in ccall, but then you would not see the modifications)
>>
>> Also, is there any reason that resourceNumber::Int should be rather than
>>> resourceNumber::Cint?
>>
>>
>> Oversight on my part. When interfacing with C it is a good idea to use
>> the C* aliases because they will take care of some cross-platform
>> peculiarities.
>>
>> kills my IJulia kernel...are there any good ways to debug the external C
>>> calls?
>>
>>
>> The best way is to use a debugger, gdb or lldb (though admittedly a bit
>> of a learning curve). Try running your test under the basic Julia shell;
>> that should give you a backtrace at least. If you want to post your code
>> somewhere (e.g. gist.github.com) I could have a look.
>>
>> Isaiah
>>
>>
>>
>> On Sat, Apr 18, 2015 at 7:12 AM, Simon Frost <[email protected]> wrote:
>>
>>> Dear Isaiah,
>>>
>>> Thanks, this has all really helped. Is the use of an array here:
>>>
>>> retInfo = [BeagleInstanceDetails(0,0,0,0,0)]
>>>
>>> a way round converting things to pointers? I had initial problems as I
>>> defined
>>>
>>> retInfo = BeagleInstanceDetails(0,0,0,0,0)
>>>
>>> and didn't know how to convert it.
>>>
>>> Also, is there any reason that resourceNumber::Int should be rather than
>>> resourceNumber::Cint?
>>>
>>> I've wrapped the complete example, but the last function call
>>>
>>> ccall((:beagleCalculateRootLogLikelihoods, "libhmsbeagle"),
>>> Int,
>>> (Cint,Ptr{Cint},Ptr{Cint},Ptr{Cint},Ptr{Cint},Cint,Ptr{Cdouble}),
>>>
>>> instance,rootIndex,categoryWeightIndex,stateFrequencyIndex,cumulativeScaleIndex,1,logL)
>>>
>>> kills my IJulia kernel...are there any good ways to debug the external C
>>> calls?
>>>
>>> Best
>>> Simon
>>>
>>
>>
