Segmentation Fault

Discussion in 'C Programming' started by Christian Lande, Jun 22, 2004.

  1. Hi all,

    can anybody help me with the following code:

    #include <stdio.h>
    #include <emmintrin.h>
    #define M 2
    int main () {
    int i;
    __m128d *s, ts, td;

    double *p = malloc(M*sizeof(*p)); //A
    // double p[2]; //B

    if (p==NULL) return 0;

    p[0]=p[1]=1.0;

    printf("%.3f %.3f\n", p[0], p[1]);

    s = (__m128d *)p; //D
    if (s != p) return 0;
    ts = *s;
    td = _mm_add_pd(ts, ts);
    *s = td; //C

    printf("%.3f %.3f\n", p[0], p[1]);
    }

    Line "C" causes a Segmentation Fault and I don't know why. If I replace line
    "A" with line "B" it works correctly. Something must be wrong with line "D"
    maybe somebody knows what?

    Thanks for any help,
    ChL

    PS: I'm using an Intel Compiler icc version 8.0 on a Xeon machine compiling
    with the command "icc test.c -o test -march=pentium4".
     
    Christian Lande, Jun 22, 2004
    #1
    1. Advertising

  2. "Christian Lande" <> wrote in
    news:cb9lot$fn2$04$-online.com:

    > Hi all,
    >
    > can anybody help me with the following code:
    >
    > #include <stdio.h>
    > #include <emmintrin.h>
    > #define M 2
    > int main () {
    > int i;
    > __m128d *s, ts, td;
    >
    > double *p = malloc(M*sizeof(*p)); //A
    > // double p[2]; //B
    >
    > if (p==NULL) return 0;
    >
    > p[0]=p[1]=1.0;
    >
    > printf("%.3f %.3f\n", p[0], p[1]);
    >
    > s = (__m128d *)p; //D


    What the heck is __m128d? Hint: it's not ISO C so how can we help you
    here?


    --
    - Mark ->
    --
     
    Mark A. Odell, Jun 22, 2004
    #2
    1. Advertising

  3. "Mark A. Odell" <> wrote:

    > What the heck is __m128d? Hint: it's not ISO C so how can we help you
    > here?


    yes, you are right, it's not ISO C, sorry. But I don't know any other
    position where to ask such a question and I'm sure here are some people who
    know the answer.

    If you are interested in what is __m128d, you can look here
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/vclrf__m128d.asp
    e.g. Some other compilers (like Intel icc for linux and windows) implement
    it in the same way.

    Thx for your answer,
    ChL
     
    Christian Lande, Jun 22, 2004
    #3
  4. On Tue, 22 Jun 2004, Christian Lande wrote:

    > Hi all,
    >
    > can anybody help me with the following code:
    >
    > #include <stdio.h>
    > #include <emmintrin.h>


    Have no idea what this header is. Without an explanation this could have
    some impact.

    > #define M 2
    > int main () {
    > int i;
    > __m128d *s, ts, td;


    What is __m128d? This is not a standard data type.

    > double *p = malloc(M*sizeof(*p)); //A


    First use of malloc without prototype. You need to add an #include
    <stdlib.h> to your program.

    > // double p[2]; //B
    >
    > if (p==NULL) return 0;
    >
    > p[0]=p[1]=1.0;
    >
    > printf("%.3f %.3f\n", p[0], p[1]);
    >
    > s = (__m128d *)p; //D


    Here I still have no idea what __m128d is and how it will affect things.

    > if (s != p) return 0;


    This tells me that the implicit conversion and explicit conversion must be
    the same to get passed this point. Is sizeof *p == sizeof *s? If not then
    what is going on here?

    > ts = *s;
    > td = _mm_add_pd(ts, ts);
    > *s = td; //C


    Is this definitely C? The use of C++ style comments makes me wonder. If it
    is C, sizeof *p < sizeof *s could cause a crash here. Or are you assuming
    that sizeof p[0] + sizeof p[1] == sizeof *s?

    If that is the case, why not use a union that contains pointers to
    doubles and a pointer to a __m128d. It would be more clear and the
    compiler might catch something you are missing.

    > printf("%.3f %.3f\n", p[0], p[1]);


    P.S. if main returns an int, where is your return statement?

    > }
    >
    > Line "C" causes a Segmentation Fault and I don't know why. If I replace line
    > "A" with line "B" it works correctly. Something must be wrong with line "D"
    > maybe somebody knows what?
    >
    > Thanks for any help,
    > ChL
    >
    > PS: I'm using an Intel Compiler icc version 8.0 on a Xeon machine compiling
    > with the command "icc test.c -o test -march=pentium4".
    >
    >
    >


    --
    Send e-mail to: darrell at cs dot toronto dot edu
    Don't send e-mail to
     
    Darrell Grainger, Jun 22, 2004
    #4
  5. "Christian Lande" <> wrote:
    >Hi all,
    >
    >can anybody help me with the following code:
    >
    >#include <stdio.h>
    >#include <emmintrin.h>


    As Mark already pointed out, by including this header you left
    the realm of portable standard C.

    >#define M 2
    >int main () {
    > int i;
    > __m128d *s, ts, td;
    >
    > double *p = malloc(M*sizeof(*p)); //A


    You forgot to #include <stdlib.h> before calling malloc; this might
    well be the reason for the problem.

    >// double p[2]; //B
    >
    > if (p==NULL) return 0;
    >
    > p[0]=p[1]=1.0;
    >
    > printf("%.3f %.3f\n", p[0], p[1]);
    >
    > s = (__m128d *)p; //D
    > if (s != p) return 0;
    > ts = *s;
    > td = _mm_add_pd(ts, ts);
    > *s = td; //C
    >
    > printf("%.3f %.3f\n", p[0], p[1]);
    >}
    >
    >Line "C" causes a Segmentation Fault and I don't know why.


    If including stdlib.h didn't fix the code, here's another possible
    cause for the segfault: if an object of type __m128d (whatever that
    is) requires more memory than p points to, you write to memory your
    program doesn't own in line "C".

    <snip>

    Regards
    --
    Irrwahn Grausewitz ()
    welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
    clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
    clc OT guide : http://benpfaff.org/writings/clc/off-topic.html
     
    Irrwahn Grausewitz, Jun 22, 2004
    #5
  6. Christian Lande

    Dan Pop Guest

    In <cb9lot$fn2$04$-online.com> "Christian Lande" <> writes:

    >#include <stdio.h>
    >#include <emmintrin.h>


    ???

    >#define M 2
    >int main () {
    > int i;
    > __m128d *s, ts, td;


    I assume __m128d is an 128-bit (16 byte) type.

    > double *p = malloc(M*sizeof(*p)); //A
    >// double p[2]; //B
    >
    > if (p==NULL) return 0;
    >
    > p[0]=p[1]=1.0;
    >
    > printf("%.3f %.3f\n", p[0], p[1]);
    >
    > s = (__m128d *)p; //D
    > if (s != p) return 0;

    ^^^^^^
    Is the compiler silently accepting this line? It doesn't look like
    __m128d is merely an alias for double and you can't compare pointers to
    different types.

    > ts = *s;


    If this works, then //C should, in principle, work, too.

    > td = _mm_add_pd(ts, ts);
    > *s = td; //C


    The only explanation for a failure here after the success of "ts = *s;"
    is that the _mm_add_pd(ts, ts) call invoked undefined behaviour.

    > printf("%.3f %.3f\n", p[0], p[1]);
    >}
    >
    >Line "C" causes a Segmentation Fault and I don't know why. If I replace line
    >"A" with line "B" it works correctly.


    This replacement generates a different stack layout, so it may be a red
    herring.

    >Something must be wrong with line "D" maybe somebody knows what?


    In this case, "ts = *s;" should have generated the crash. But this
    didn't happen, so the pointer value is OK.

    >Thanks for any help,
    >ChL
    >
    >PS: I'm using an Intel Compiler icc version 8.0 on a Xeon machine compiling
    >with the command "icc test.c -o test -march=pentium4".


    Your code is not standard C code and your problem has nothing to do
    with standard C.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jun 22, 2004
    #6
  7. Christian Lande

    Dan Pop Guest

    In <> Irrwahn Grausewitz <> writes:

    >"Christian Lande" <> wrote:
    >>Hi all,
    >>
    >>can anybody help me with the following code:
    >>
    >>#include <stdio.h>
    >>#include <emmintrin.h>

    >
    >As Mark already pointed out, by including this header you left
    >the realm of portable standard C.
    >
    >>#define M 2
    >>int main () {
    >> int i;
    >> __m128d *s, ts, td;
    >>
    >> double *p = malloc(M*sizeof(*p)); //A

    >
    >You forgot to #include <stdlib.h> before calling malloc; this might
    >well be the reason for the problem.


    If he did, indeed, the compiler should have complained: a diagnostic is
    required.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jun 22, 2004
    #7
  8. Ok, thanks to all of you for reading and trying to help, meanwhile I solved
    the problem.

    It was because of the fact, that this __m128d-type was defined with an
    alignment of every 16 Bytes, so I got the problem because of my reserved
    double field has an alignment of every 8 Bytes.

    Because of your comments that this is not the right group, can you give me a
    hint where to ask for such things, please? These problems occouring from
    time to time and I've allways the same problem not knowing where to ask for.

    Thx,
    ChL
     
    Christian Lande, Jun 22, 2004
    #8
  9. Christian Lande

    CBFalconer Guest

    Christian Lande wrote:
    >
    > can anybody help me with the following code:
    >
    > #include <stdio.h>
    > #include <emmintrin.h>


    unknown header.

    > #define M 2
    > int main () {


    int main (void) is better

    > int i;
    > __m128d *s, ts, td;


    illegal identifier __m128d. Reserved for implementation

    >
    > double *p = malloc(M*sizeof(*p)); //A
    > // double p[2]; //B


    // comments are ill advised in newsgroups, require C99 compiler.
    You probably don't have one. Use /* ... */ instead.

    >
    > if (p==NULL) return 0;
    >
    > p[0]=p[1]=1.0;
    >
    > printf("%.3f %.3f\n", p[0], p[1]);
    >
    > s = (__m128d *)p; //D


    Again, unideclared and illegal identifier. Bad comment.

    > if (s != p) return 0;


    Why should it be? They point to different types.

    > ts = *s;


    ts is of type blah, s of type pointer to blah (I won't sink to
    typing __m128d). Even more things must be undefined by now.

    > td = _mm_add_pd(ts, ts);


    Another illegal identifier, also undefined.

    > *s = td; //C
    >
    > printf("%.3f %.3f\n", p[0], p[1]);
    > }
    >
    > Line "C" causes a Segmentation Fault and I don't know why. If I
    > replace line "A" with line "B" it works correctly. Something must
    > be wrong with line "D" maybe somebody knows what?
    >
    > Thanks for any help,
    > ChL
    >
    > PS: I'm using an Intel Compiler icc version 8.0 on a Xeon machine
    > compiling with the command "icc test.c -o test -march=pentium4".


    If that matters you are off topic.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
     
    CBFalconer, Jun 22, 2004
    #9
  10. Christian Lande

    CBFalconer Guest

    Christian Lande wrote:
    >

    .... snip ...
    >
    > Because of your comments that this is not the right group, can
    > you give me a hint where to ask for such things, please? These
    > problems occouring from time to time and I've allways the same
    > problem not knowing where to ask for.


    Your best bet is to stick to pure ISO standard portable C and
    eschew system specific extensions. The end convenience will pay
    for itself many times over.

    If this is not possible you should, in this case, look for a
    newsgroup with 'Microsoft' in its name. In that case you should
    also isolate your non-portable code to a file or two.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
     
    CBFalconer, Jun 23, 2004
    #10
  11. On Tue, 22 Jun 2004 18:13:00 +0200, "Christian Lande"
    <> wrote:

    >Hi all,
    >
    >can anybody help me with the following code:
    >
    >#include <stdio.h>
    >#include <emmintrin.h>
    >#define M 2
    >int main () {
    > int i;
    > __m128d *s, ts, td;
    >
    > double *p = malloc(M*sizeof(*p)); //A
    >// double p[2]; //B
    >
    > if (p==NULL) return 0;
    >
    > p[0]=p[1]=1.0;
    >
    > printf("%.3f %.3f\n", p[0], p[1]);
    >
    > s = (__m128d *)p; //D
    > if (s != p) return 0;


    Doesn't your compiler generate a diagnostic for this? The two pointer
    types are incompatible unless __m128d is just a typedef for double.

    > ts = *s;
    > td = _mm_add_pd(ts, ts);
    > *s = td; //C


    What is the sizeof(__m128d)? If it is larger than 2*sizeof(double)
    you are attempting to write to memory you don't own.

    >
    > printf("%.3f %.3f\n", p[0], p[1]);
    >}
    >
    >Line "C" causes a Segmentation Fault and I don't know why. If I replace line
    >"A" with line "B" it works correctly. Something must be wrong with line "D"


    If it is the size problem mentioned above, line C will overwrite other
    variables in your program but at least you own that memory.

    However, both overwrites invoke undefined behavior so it really won't
    work even if it appears to.

    >maybe somebody knows what?


    With line A, line D cannot be the problem because the value returned
    from malloc is guaranteed to be properly aligned for any type,
    including __m128d. With line B, we don't know if p will be properly
    aligned.

    If you really want help, you are going to have to give us all the
    non-standard details. What is type __m128d? What does _mm_add_pd do?


    <<Remove the del for email>>
     
    Barry Schwarz, Jun 23, 2004
    #11
  12. Christian Lande wrote:
    > #include <emmintrin.h>
    > #define M 2
    > __m128d *s, ts, td;
    >
    > double *p = malloc(M*sizeof(*p)); //A
    > // double p[2]; //B
    >
    > if (p==NULL) return 0;
    >
    > p[0]=p[1]=1.0;
    >
    > printf("%.3f %.3f\n", p[0], p[1]);
    >
    > s = (__m128d *)p; //D
    > if (s != p) return 0;
    > ts = *s;
    > td = _mm_add_pd(ts, ts);
    > *s = td; //C
    >
    > printf("%.3f %.3f\n", p[0], p[1]);
    > }
    >
    > Line "C" causes a Segmentation Fault and I don't know why.
    > If I replace line "A" with line "B" it works correctly.
    > Something must be wrong with line "D" maybe somebody knows what?


    Casts are always wrong, only that they sometimes are the only cure. Here
    however, you say that it should interpret the address 'p' as a '__m128d*'.
    'd' only holds so much storage, so why don't you first make sure that
    there is enough?

    $include <assert.h>
    assert( (sizeof *s) <= (M * (sizeof *p)));

    The fact that it does seem to work with 'B' activated is just luck. Try
    adding another var after p, and output its value before and after 'C'. The
    stack area was already allocated to your process, but that doesn't mean
    you are allowed to use it. The heap is allocated more exactly to fit your
    needs, crossing these bounds therefore earlier causes the segmentation
    fault.

    Oh, while you are at it, could you please remove everything that is not
    necessary to demonstrate your problem, e.g. the call to _mm_add_pd()?

    Uli

    --
    FAQ: http://ma.rtij.nl/acllc-c .FAQ.html
     
    Ulrich Eckhardt, Jun 23, 2004
    #12
  13. Darrell Grainger wrote:
    > On Tue, 22 Jun 2004, Christian Lande wrote:
    >> *s = td; //C

    >
    > Is this definitely C? The use of C++ style comments makes me wonder.


    C allows those comments. It didn't always allow them, but it does now (and
    many compilers have been accepting it for some time).

    Uli
     
    Ulrich Eckhardt, Jun 23, 2004
    #13
  14. Christian Lande

    Ravi Uday Guest

    Comments inline..

    "Christian Lande" <> wrote in message news:<cb9lot$fn2$04$-online.com>...
    > Hi all,
    >
    > can anybody help me with the following code:
    >
    > #include <stdio.h>
    > #include <emmintrin.h>


    Never heard of this header. System specific headers are not discussed
    here..

    > #define M 2
    > int main () {
    > int i;
    > __m128d *s, ts, td;


    /* whats this __m128d ... its not a C datatype that i've known. */
    >
    > double *p = malloc(M*sizeof(*p)); //A
    > // double p[2]; //B
    >
    > if (p==NULL) return 0;
    >
    > p[0]=p[1]=1.0;
    >
    > printf("%.3f %.3f\n", p[0], p[1]);
    >
    > s = (__m128d *)p; //D


    /* Unless you tell us whats __m128d stands for how can we know
    whats happ ?*/

    > if (s != p) return 0;
    > ts = *s;
    > td = _mm_add_pd(ts, ts);


    /* mm_add_pd.. where is this defined ! I think its in this function
    the culprit is, there is some inconsistency in the params you have
    passed. Did you make a typo !!!! */
    > *s = td; //C
    >
    > printf("%.3f %.3f\n", p[0], p[1]);
    > }


    Since main is declared as function that returns 'int' before exiting
    the function, call return with 0/EXIT_FAILURE..etc..

    >
    > Line "C" causes a Segmentation Fault and I don't know why. If I replace line
    > "A" with line "B" it works correctly. Something must be wrong with line "D"
    > maybe somebody knows what?
    >
    > Thanks for any help,
    > ChL
    >


    Its better you post here a compilable code for us to run/exec and test
    your program. By this we can make our statements/suggestions clear and
    crisp.
     
    Ravi Uday, Jun 23, 2004
    #14
  15. "CBFalconer" <> wrote:

    > If this is not possible you should, in this case, look for a
    > newsgroup with 'Microsoft' in its name.


    I don't understand this suggestion. What should the code in a
    'Microsoft'-Group, it was coded for a Xeon with Red Hat Linux?

    > In that case you should
    > also isolate your non-portable code to a file or two.


    For what reason? In most groups attachments are not not gladly seen.

    Thx for your answer,
    ChL
     
    Christian Lande, Jun 23, 2004
    #15
  16. Christian Lande

    Chris Dollin Guest

    Christian Lande wrote:

    > "CBFalconer" <> wrote:


    >> In that case you should
    >> also isolate your non-portable code to a file or two.

    >
    > For what reason? In most groups attachments are not not gladly seen.


    Not in your postings - in your actual code.

    Putting the non-portable bits in their own file(s) makes it easier
    to replace them on a different platform than if the platform-dependencies
    are wrapped in ifdefs and scattered all round your source.

    --
    Chris "electric hedgehog" Dollin
    C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html
    C welcome: http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html
     
    Chris Dollin, Jun 23, 2004
    #16
  17. On Wed, 23 Jun 2004, Christian Lande wrote:
    >
    > "CBFalconer" <> wrote:
    > > If this is not possible you should, in this case, look for a
    > > newsgroup with 'Microsoft' in its name.

    >
    > I don't understand this suggestion. What should the code in a
    > 'Microsoft'-Group, it was coded for a Xeon with Red Hat Linux?


    Then you should look for a group with 'linux' in its name. Duh.
    (If you specify an Intel architecture without specifying the OS, most
    people will assume you're a Microsoft user. Especially if you come
    off as clueless.)

    > > In that case you should
    > > also isolate your non-portable code to a file or two.

    >
    > For what reason? In most groups attachments are not not gladly seen.


    He said "file," as in "source file." Attachments have nothing to
    do with it. The point is that in a well-written program, the only
    system dependencies ought to be easily locatable and modifiable. The
    easiest way to do this is to put all of them in a separate source
    file, called 'linuxdep.c' or some such. Then it will be much easier
    to port the program to use another OS, architecture, or special-purpose
    library.

    HTH,
    -Arthur
     
    Arthur J. O'Dwyer, Jun 23, 2004
    #17
  18. Christian Lande

    Dan Pop Guest

    In <> Ulrich Eckhardt <> writes:

    >Casts are always wrong, only that they sometimes are the only cure. Here


    If the *only* way of *correctly* writing a piece of code requires a cast,
    how can you claim that they are always wrong?

    There are plenty of good uses of casts and there are also cases where
    the language definition imposes the usage of dubious casts (try to
    implement strchr if you need an example).

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jun 23, 2004
    #18
  19. Christian Lande

    Dan Pop Guest

    In <> Ulrich Eckhardt <> writes:

    >Darrell Grainger wrote:
    >> On Tue, 22 Jun 2004, Christian Lande wrote:
    >>> *s = td; //C

    >>
    >> Is this definitely C? The use of C++ style comments makes me wonder.

    >
    >C allows those comments. It didn't always allow them, but it does now (and
    >many compilers have been accepting it for some time).


    A conforming C89 compiler *must* diagnose them. A conforming C99 compiler
    must accept them, but conforming C99 compilers are few and far between.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jun 23, 2004
    #19
  20. Christian Lande

    Dan Pop Guest

    In <cb9tdq$utr$03$-online.com> "Christian Lande" <> writes:

    >Ok, thanks to all of you for reading and trying to help, meanwhile I solved
    >the problem.
    >
    >It was because of the fact, that this __m128d-type was defined with an
    >alignment of every 16 Bytes, so I got the problem because of my reserved
    >double field has an alignment of every 8 Bytes.


    But then, the attempt to read from that address should have crashed your
    code, which survived until attempting to write to that address...

    >Because of your comments that this is not the right group, can you give me a
    >hint where to ask for such things, please?


    Since you say you're using a Microsoft extension, try a newsgroup whose
    name starts with microsoft.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jun 23, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Alex Hunsley
    Replies:
    17
    Views:
    896
  2. Pud
    Replies:
    0
    Views:
    608
  3. Replies:
    0
    Views:
    573
  4. Ivan Vecerina
    Replies:
    0
    Views:
    507
    Ivan Vecerina
    Jun 29, 2003
  5. Vasileios Zografos

    Re: segmentation fault exception handling

    Vasileios Zografos, Jun 30, 2003, in forum: C++
    Replies:
    5
    Views:
    15,749
    Pete Becker
    Jul 1, 2003
Loading...

Share This Page