When -lm is linked statically, segmentation fault on run time - dumps core on 14.04.1 LTS on 64 bit AMD

Question

The codes in C has been running fine on Ubuntu 14.04.1 LTS on 64 bit AMD C50x2. When "-lm" linked statically and ran the same test on the same environment, it dumps core on run time. It also passed the ldd test. Only thing that was changed was "-lm" was statically linked:

gcc .... -static -lm Later tried with the full path for the "-lm" library - it dumped core again.

Tried with the trace command:

execve("./mypro", ["./mypro"], [/* 61 vars */]) = 0
uname({sys="Linux", node="Acer", ...})  = 0
brk(0)                                  = 0x2668000
brk(0x26691c0)                          = 0x26691c0
arch_prctl(ARCH_SET_FS, 0x2668880)      = 0
readlink("/proc/self/exe", "/home/owner/wfiles/mypro", 4096) = 23
brk(0x268a1c0)                          = 0x268a1c0
brk(0x268b000)                          = 0x268b000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
write(2, "Expecting two argume"..., 35Expecting two argument
) = 35
exit_group(1)                           = ?
+++ exited with 1 +++ 

Update: 1) I only had one library. Also, the order as I compiled:

gcc a.c b.c -o myprogramEXE -static -lm

2) I ran gdb and bactrace - the issue is possibly something to do with Linux and malloc. Part of the code was taken from Numerical Recipie in C (NRC) which used -

void    *malloc(int);

It was incompatible to Linux and in lieu of it, I added another include file. The segmentation fault occurs on this function below from NRC, where it says free():

void free_vector(v,nl,nh)
float *v;
int nl, nh;
/* Frees a float vector allocated by vector().    */
{
    free((char*) (v+nl)); 
}

The following function was used by NRC to create the vector:

float *vector (nl,nh)
int nl, nh;
{
    float *v;

    v=(float *)malloc((unsigned) (nh-nl+1)*sizeof(float));
    if (!v) nrerror("allocation failure in vector()");
    return v-nl;
}

How can I fix the issue - why it happens when there is a static link on the same build environ?

Update2: I found revised codes on NRC web site - however my prob is not resolved. http://www.nr.com/pubdom/nrutil.c.txt

void free_vector(float *v, long nl, long nh)
/* free a float vector allocated with vector() */
{
    free((char*) (v+nl-1));
}

float *vector(long nl, long nh)
/* allocate a float vector with subscript range v[nl..nh] */
{
    float *v;

    v=(float *)malloc((size_t) ((nh-nl+1+1)*sizeof(float)));
    if (!v) nrerror("allocation failure in vector()");
    return v-nl+1;
}

Answer 1

return v-nl; causes undefined behaviour.

Pointers may only point to an element of an array (or one past the last element). Writing v - nl tries to form a pointer into the middle of nowhere.

It would be a good idea to redesign this code to not rely on undefined behaviour.

---

You mention void *malloc(int);, however that would be a bug. The proper signature is void *malloc(size_t);.

In any case you should write #include <stdlib.h> instead, to avoid any possibility of error.

Answer 2

The reason it might dump core under one circumstance (linked with -static -lm) and not otherwise is that the linkage has changed the memory layout - but the program is still misbehaving, just in a way that's not obvious (yet.)

I don't have "Numerical Recipies in C" handy, but if you've retyped the code examples into your own program, I suspect a typographical error.

In your "free_vector(float *v, int nl, int nh)" example, 'v' is a 1 dimensional array of "floats". The expression "v+nl" in your call to "free()" is the same as "&(v[nl])" - i.e.: you're trying to free the 'nl'th element of the array which doesn't make a lot of sense. (If 'v' was an array of POINTERS to floats it would make sense, but then 'v' would be declared as "float *v[]" or "float **v".)

I'm presuming that 'v' (allocated by "vector()") is supposed to be a 1 dimensional array (vector) of floats OR pointers to floats (that's uncertain yet.) The 'nl' and 'nh' seem to be array (vector) index bounds so that you can have arrays bounded from 1 to n instead of 0 to n-1 (or some other range, like 5 to 9) and the "vector()" function takes care of allocating 'v'. Beyond that, I can't guess.