A simple initialization results in a segfault

[dmbates]

Using version 4.3 of SuperLU on an Ubuntu 13.10 amd_64 system I get with julia-debug

(gdb) run
Starting program: /home/bates/build/julia/./usr/bin/julia-debug-basic 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff2bd3700 (LWP 12029)]
               _
   _       _ _(_)_     |  A fresh approach to technical computing
  (_)     | (_) (_)    |  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "help()" to list help topics
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.3.0-prerelease+407 (2013-12-12 15:50 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit 48e350f* (0 days old master)
|__/                   |  x86_64-pc-linux-gnu

julia> using SuperLU

julia> v = [apply(SuperLUStat_t,map(zero,SuperLUStat_t.types))]
1-element Array{SuperLUStat_t,1}:
 SuperLUStat_t(Ptr{Int32} @0x0000000000000000,Ptr{Float64} @0x0000000000000000,Ptr{Float32} @0x0000000000000000,0,0,0)

julia> ccall((:StatInit,:libsuperlu),Void,(Ptr{SuperLUStat_t},),v)

julia> v
1-element Array{SuperLUStat_t,1}:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff71e2d6f in jl_is_vararg_type (v=0x0) at ./julia.h:633
633     return (jl_is_datatype(v) &&
(gdb) bt
#0  0x00007ffff71e2d6f in jl_is_vararg_type (v=0x0) at ./julia.h:633
#1  0x00007ffff71e82e3 in jl_tuple_subtype_ (child=0x3e9c870, cl=2, parent=0x1547bf0, pl=2, ta=0, 
    morespecific=0, invariant=0) at jltypes.c:1866
#2  0x00007ffff71e822f in jl_tuple_subtype (child=0x3e9c870, cl=2, parent=0x1547bf0, pl=2, ta=0, 
    morespecific=0) at jltypes.c:1911
#3  0x00007ffff71f0761 in jl_mt_assoc_by_type (mt=0x1520920, tt=0x3e9c860, cache=1, inexact=0)
    at gf.c:901
#4  0x00007ffff71f12b2 in jl_apply_generic (F=0x1547bc0, args=0x7fffffffc8f0, nargs=2) at gf.c:1345
#5  0x00007ffff71facb4 in jl_apply (f=0x1547bc0, args=0x7fffffffc8f0, nargs=2) at ./julia.h:1040
#6  0x00007ffff71faa11 in jl_f_apply (F=0x15c2ce0, args=0x7fffffffca18, nargs=3) at builtins.c:292
#7  0x00007ffff4aa0566 in ?? ()
#8  0x000000000000000c in ?? ()
#9  0x00007fffffffcae8 in ?? ()
#10 0x0000000003e73748 in ?? ()
#11 0x0000000003e827d0 in ?? ()
#12 0x0000000003e93d40 in ?? ()
#13 0x0000000001547bc0 in ?? ()
#14 0x0000000003e73760 in ?? ()
#15 0x0000000003e73748 in ?? ()
#16 0xb105a29ed2f0f400 in ?? ()
#17 0x00007fffffffcb08 in ?? ()
#18 0x0000000001243ef0 in ?? ()
#19 0x0000000000000000 in ?? ()

It doesn't appear to me that anything peculiar is going on in the C function StatInit, whose source is

void
StatInit(SuperLUStat_t *stat)
{
    register int i, w, panel_size, relax;

    panel_size = sp_ienv(1);
    relax = sp_ienv(2);
    w = SUPERLU_MAX(panel_size, relax);
    stat->panel_histo = intCalloc(w+1);
    stat->utime = (double *) SUPERLU_MALLOC(NPHASES * sizeof(double));
    if (!stat->utime) ABORT("SUPERLU_MALLOC fails for stat->utime");
    stat->ops = (flops_t *) SUPERLU_MALLOC(NPHASES * sizeof(flops_t));
    if (!stat->ops) ABORT("SUPERLU_MALLOC fails for stat->ops");
    for (i = 0; i < NPHASES; ++i) {
        stat->utime[i] = 0.;
        stat->ops[i] = 0.;
    }
    stat->TinyPivots = 0;
    stat->RefineSteps = 0;
    stat->expansions = 0;
#if ( PRNTlevel >= 1 )
    printf(".. parameters in sp_ienv():\n");
    printf("\t 1: panel size \t %4d \n"
           "\t 2: relax      \t %4d \n"
           "\t 3: max. super \t %4d \n"
           "\t 4: row-dim 2D \t %4d \n"
           "\t 5: col-dim 2D \t %4d \n"
           "\t 6: fill ratio \t %4d \n",
       sp_ienv(1), sp_ienv(2), sp_ienv(3), 
       sp_ienv(4), sp_ienv(5), sp_ienv(6));
#endif
}

Without special flags in the compilation of libsuperlu SUPERLU_MALLOC ends up calling the system malloc through a function called superlu_malloc.

I am using a prerelease version of a Debian package libsuperlu4 which puts the shared object libsuperlu.so in /usr/lib. I would write a

provides(Sources,...)

but that is a bit beyond my knowledge of the BinDeps package at this time. One problem is that the Makefile in the distributed sources only produces the static library.

[ihnorton]

Is there a .deb available for libsuperlu4? I looked around but couldn't find one.

Can you try v.T for each T in SuperLUStat_t.types to see which one it is choking on? (this seems like a show issue)

[vtjnash]

this probably needs JuliaLang/julia#2818

[vtjnash]

I think you want:

v = apply(SuperLUStat_t,map(zero,SuperLUStat_t.types))
ccall((:StatInit,:libsuperlu),Void,(Ptr{SuperLUStat_t},),&v)

[dmbates]

Thanks, @vtjnash . Your suggestion worked.

I was confused because I knew that to pass a pointer to a bitstype where you want to overwrite the contents you needed to create a vector of length 1 and pass that. I hadn't realized that it done the other way when passing a pointer to a struct.

[dmbates]

@ihnorton The Debian package for libsuperlu4 is still in the incoming queue on Debian. Sébastien Villemot was kind enough to make it available through

dget -x http://people.debian.org/~sebastien/superlu_4.3+dfsg-1.dsc

[vtjnash]

I was confused because I knew that to pass a pointer to a bitstype where you want to overwrite the contents you needed to create a vector of length 1 and pass that. I hadn't realized that it done the other way when passing a pointer to a struct.

agreed. i want to improve this situation (reduce confusion).