seg fault in linux but not cygwin

Discussion in 'C Programming' started by johnty, Feb 10, 2010.

  1. johnty

    johnty Guest

    i'm facing a rather baffling problem:

    calling a function in a FOR loop. the function has the following
    lines:

    clock_gettime(CLOCK_REALTIME, &time_stamp);
    srand(time_stamp.tv_nsec);

    the idea is each time it is called the random number generator is
    seeded with the current nanosecond counter.

    the program causes a seg fault when running in linux after 2 loops,
    but not in cygwin. when the two lines are commented out, the code runs
    fine in both.

    any ideas why? or could the problem actually be somewhere else?

    thanks!

    johnty
    johnty, Feb 10, 2010
    #1
    1. Advertising

  2. On Feb 10, 1:34 pm, johnty <> wrote:
    > i'm facing a rather baffling problem:
    >
    > calling a function in a FOR loop. the function has the following
    > lines:
    >
    >         clock_gettime(CLOCK_REALTIME, &time_stamp);
    >         srand(time_stamp.tv_nsec);
    >
    > the idea is each time it is called the random number generator is
    > seeded with the current nanosecond counter.
    >
    > the program causes a seg fault when running in linux after 2 loops,
    > but not in cygwin. when the two lines are commented out, the code runs
    > fine in both.
    >
    > any ideas why? or could the problem actually be somewhere else?
    >

    Make usre that time_stamp is genuinely a structure of the right type
    to pass to clock_gettime. If clock_gettime is a library function it is
    very unlikely, though possible, that it would segfault on legitimate
    input.

    Try adding a srand(1) to the program after the call to srand. That
    will help to keep the program deterministic, which might uncover the
    problem.

    However the root of the problem might be elsewhere. Once you have a
    loose pointer, anything can happen. Commenting out the code could
    change the layout of variables in memory so the losse pointer hits
    something different, which doesn't raise the segfault.
    Malcolm McLean, Feb 10, 2010
    #2
    1. Advertising

  3. On Feb 10, 1:34 pm, johnty <> wrote:
    > i'm facing a rather baffling problem:
    >
    > calling a function in a FOR loop. the function has the following
    > lines:
    >
    >         clock_gettime(CLOCK_REALTIME, &time_stamp);
    >         srand(time_stamp.tv_nsec);
    >
    > the idea is each time it is called the random number generator is
    > seeded with the current nanosecond counter.
    >
    > the program causes a seg fault when running in linux after 2 loops,
    > but not in cygwin. when the two lines are commented out, the code runs
    > fine in both.
    >
    > any ideas why? or could the problem actually be somewhere else?


    I can't reproduce your segfault on linux (Ubuntu, 2.6.31, SMP). Your
    problem probably lies somewhere else. A complete snippet and/or a
    relevant backtrace/error log would be more helpful.
    Michael Foukarakis, Feb 10, 2010
    #3
  4. johnty

    santosh Guest

    johnty wrote:
    > i'm facing a rather baffling problem:
    >
    > calling a function in a FOR loop. the function has the following
    > lines:
    >
    > clock_gettime(CLOCK_REALTIME, &time_stamp);
    > srand(time_stamp.tv_nsec);


    I hope that in your actual code you cast the long value to unsigned in
    the srand() call above.

    > the idea is each time it is called the random number generator is
    > seeded with the current nanosecond counter.
    >
    > the program causes a seg fault when running in linux after 2 loops,
    > but not in cygwin. when the two lines are commented out, the code runs
    > fine in both.
    >
    > any ideas why? or could the problem actually be somewhere else?


    With the information given, one can't really say. Can you provide a
    minimal program that exhibits your problem? Or atleast the full source
    for the function that contains the above loop?
    santosh, Feb 10, 2010
    #4
  5. johnty

    Nobody Guest

    On Wed, 10 Feb 2010 03:34:11 -0800, johnty wrote:

    > i'm facing a rather baffling problem:
    >
    > calling a function in a FOR loop. the function has the following
    > lines:
    >
    > clock_gettime(CLOCK_REALTIME, &time_stamp);
    > srand(time_stamp.tv_nsec);


    The tv_nsec field is a long, but srand() expects an int; that may matter
    on a 64-bit system if the prototype for srand() isn't in scope (although
    it's unlikely to result in a segfault).

    OTOH, if the prototype for srand() is in scope, you should have gotten a
    warning. Turn up the compiler's warning level (use at least -Wall) and
    ensure that the program compiles without warnings.

    > or could the problem actually be somewhere else?


    Quite possibly.
    Nobody, Feb 10, 2010
    #5
  6. johnty

    johnty Guest

    thanks for the prompt replies!

    man its really early in the morning... i didn't quite say it right.
    (but have a feeling the replies are pointing in the right direction)

    instead of:

    >the program causes a seg fault when running in linux after 2 loops,
    >but not in cygwin. when the two lines are commented out, the code runs
    >fine in both.


    what i meant to say was:

    in linux, the seg fault happens when the lines are COMMENTED OUT,
    while in windows it can run with or without it.

    i'm also using the same two lines of code elsewhere without problems.
    so it makes me think it could be a loose pointer somewhere else...
    johnty, Feb 10, 2010
    #6
  7. Re: OT: Proper use of PRNGs (was: seg fault in linux but not cygwin)

    johnty wrote:

    > clock_gettime(CLOCK_REALTIME, &time_stamp);
    > srand(time_stamp.tv_nsec);
    >
    > the idea is each time it is called the random number generator is
    > seeded with the current nanosecond counter.


    This is a bad idea. Basically this resets the seed to a predictable value,
    which makes the generated numbers as well predictable. This is also clearly
    stated in the documentation:

    man clock_getres(3)
    | The resolution of clocks depends on the implementation and cannot be
    | configured by a particular process. If the time value pointed to by the
    | argument tp of clock_settime() is not a multiple of res, then it is
    | truncated to a multiple of res.

    Or in other words: The entropy of the RT clock is to be considered low.

    The standard PRNG that comes with most C standard libraries isn't very good,
    but even a PRNG suitable for cryptographic applications would produce very
    low quality randomnes if used that way.

    > the program causes a seg fault when running in linux after 2 loops,
    > but not in cygwin. when the two lines are commented out, the code runs
    > fine in both.


    Hard to tell without a look at the full code. It might be anything and not
    be related to the query of the RT clock at all. A little bit more of
    context, i.e. some working (or in this case breaking) minimal full program
    source would help.

    > or could the problem actually be somewhere else?


    Possibly.


    Wolfgang
    Wolfgang Draxinger, Feb 10, 2010
    #7
  8. Re: OT: Proper use of PRNGs (was: seg fault in linux but not cygwin)

    On 10 Feb, 12:10, Wolfgang Draxinger <-
    muenchen.de> wrote:

    > The standard PRNG that comes with most C standard libraries isn't very good,


    odd isn't it? I'm told in another thread that the typical C library
    is of such high quality that I'd be mad to use anything else. Whilst
    here I'm told the PRNGs of the typical C library are poor. Is the
    definition of srand/rand too restrictive?
    Nick Keighley, Feb 10, 2010
    #8
  9. johnty

    Rob Kendrick Guest

    Re: OT: Proper use of PRNGs (was: seg fault in linux but notcygwin)

    On Wed, 10 Feb 2010 05:05:13 -0800 (PST)
    Nick Keighley <> wrote:

    > On 10 Feb, 12:10, Wolfgang Draxinger <-
    > muenchen.de> wrote:
    >
    > > The standard PRNG that comes with most C standard libraries isn't
    > > very good,

    >
    > odd isn't it? I'm told in another thread that the typical C library
    > is of such high quality that I'd be mad to use anything else. Whilst
    > here I'm told the PRNGs of the typical C library are poor. Is the
    > definition of srand/rand too restrictive?


    Depends on the implementation on your C library, and you'd be mad to
    use the one in the C library unless you understood its properties, and
    the precise problem you're trying to solve.

    As an example, many implementations aren't even suitable for simulating
    the shuffling of a deck of cards.

    B.
    Rob Kendrick, Feb 10, 2010
    #9
  10. johnty <> writes:

    > i'm facing a rather baffling problem:
    >
    > calling a function in a FOR loop. the function has the following
    > lines:
    >
    > clock_gettime(CLOCK_REALTIME, &time_stamp);
    > srand(time_stamp.tv_nsec);
    >
    > the idea is each time it is called the random number generator is
    > seeded with the current nanosecond counter.


    Just a heads up: this is often the wrong way to use an RNG -- seeding
    it once is usually the right thing to do. If the RNG is designed
    well, that gives you the best period and the best chance of a good
    distribution of results. Most RNGs are not designed to perform well
    if they are repeatedly seeded with a monotone sequence like this
    though it is possible that your application does not care, or that
    your RNG happens to be one that is un-phased by this re-seeding.

    > the program causes a seg fault when running in linux after 2 loops,
    > but not in cygwin. when the two lines are commented out, the code runs
    > fine in both.
    >
    > any ideas why? or could the problem actually be somewhere else?


    It's impossible to say (at least for me). I'd use valgrind if you are
    able to. If the code is shortish (and you are permitted to show it)
    posting it here might help.

    --
    Ben.
    Ben Bacarisse, Feb 10, 2010
    #10
  11. johnty

    Eric Sosman Guest

    On 2/10/2010 6:50 AM, Nobody wrote:
    > On Wed, 10 Feb 2010 03:34:11 -0800, johnty wrote:
    >
    >> i'm facing a rather baffling problem:
    >>
    >> calling a function in a FOR loop. the function has the following
    >> lines:
    >>
    >> clock_gettime(CLOCK_REALTIME,&time_stamp);
    >> srand(time_stamp.tv_nsec);

    >
    > The tv_nsec field is a long, but srand() expects an int; that may matter
    > on a 64-bit system if the prototype for srand() isn't in scope (although
    > it's unlikely to result in a segfault).


    srand() takes an unsigned int, not an int.

    > OTOH, if the prototype for srand() is in scope, you should have gotten a
    > warning. Turn up the compiler's warning level (use at least -Wall) and
    > ensure that the program compiles without warnings.


    With a prototype in scope, the long value is converted to
    unsigned int "as if by assignment." No diagnostic is required,
    although (as always) the compiler is free to issue whatever
    non-required diagnostics it wants to. The gcc compiler version
    on my system does not issue diagnostics for this situation even
    with -Wall; you need -Wconversion or -Wsign-conversion to get one.

    --
    Eric Sosman
    lid
    Eric Sosman, Feb 10, 2010
    #11
  12. johnty

    Eric Sosman Guest

    Re: OT: Proper use of PRNGs

    On 2/10/2010 8:05 AM, Nick Keighley wrote:
    > On 10 Feb, 12:10, Wolfgang Draxinger<-
    > muenchen.de> wrote:
    >
    >> The standard PRNG that comes with most C standard libraries isn't very good,

    >
    > odd isn't it? I'm told in another thread that the typical C library
    > is of such high quality that I'd be mad to use anything else. Whilst
    > here I'm told the PRNGs of the typical C library are poor. Is the
    > definition of srand/rand too restrictive?


    Since the sequence generated by rand() depends entirely
    on the seed provided by srand(), and since the argument to
    srand() is an unsigned int, it follows that rand() can produce
    no more than UINT_MAX+1 different sequences. That could be as
    few as 65536, or more typically 4294967295.

    Four billion sequences may sound like a lot, but consider:
    You can shuffle a deck of fifty-two cards in 52! ~= 8e67 ways,
    which is 2e58 times four billion ... Heck, you can shuffle
    the thirteen cards of just one suit in more than four billion
    ways.

    --
    Eric Sosman
    lid
    Eric Sosman, Feb 10, 2010
    #12
  13. Re: OT: Proper use of PRNGs (was: seg fault in linux but not cygwin)

    Nick Keighley wrote:

    > odd isn't it? I'm told in another thread that the typical C library
    > is of such high quality that I'd be mad to use anything else.


    The C standard library covers a wide field: Memory management, basic
    algorithms, string manipulation, math functions.

    It's also important to define the metric by which you measure quality. Is it
    quality of the code, the overall implementation or the used algorithms.

    IMHO the API of the standard libarary is quite poor. If you worked with
    things like libowfat/libdjb then everytime you got to use the "normal"
    functions is a really painful time (but that's really IMHO).

    > Whilst here I'm told the PRNGs of the typical C library are poor. Is the
    > definition of srand/rand too restrictive?


    If you just need a small set of arbitrarily looking numbers or simply some
    random 15 bits to select an IP source port, then srand/rand will do fine. As
    soon you need a few thousand bits of randomnes for cryptography, numerical
    simulation, something like that, then your typical C standard library PRNG
    just sucks.


    Wolfgang
    Wolfgang Draxinger, Feb 10, 2010
    #13
  14. Re: OT: Proper use of PRNGs

    On Feb 10, 3:58 pm, Eric Sosman <> wrote:
    > On 2/10/2010 8:05 AM, Nick Keighley wrote:
    >
    > > On 10 Feb, 12:10, Wolfgang Draxinger<-
    > > muenchen.de>  wrote:

    >
    > >> The standard PRNG that comes with most C standard libraries isn't very good,

    >
    > > odd isn't it?  I'm told in another thread that the typical C library
    > > is of such high quality that I'd be mad to use anything else. Whilst
    > > here I'm told the PRNGs of the typical C library are poor. Is the
    > > definition of srand/rand too restrictive?

    >
    >      Since the sequence generated by rand() depends entirely
    > on the seed provided by srand(), and since the argument to
    > srand() is an unsigned int, it follows that rand() can produce
    > no more than UINT_MAX+1 different sequences.  That could be as
    > few as 65536, or more typically 4294967295.
    >
    >      Four billion sequences may sound like a lot, but consider:
    > You can shuffle a deck of fifty-two cards in 52! ~= 8e67 ways,
    > which is 2e58 times four billion ...  Heck, you can shuffle
    > the thirteen cards of just one suit in more than four billion
    > ways.


    That's a great example, actually. Just to add to that, rand() is also
    not reentrant or thread-safe, and it's documented (at least on Linux
    and BSD) to provide lower-order bits of less randomness than the high-
    order bits.
    Michael Foukarakis, Feb 10, 2010
    #14
  15. johnty

    osmium Guest

    Re: OT: Proper use of PRNGs (was: seg fault in linux but not cygwin)

    "Nick Keighley" wrote:

    > On 10 Feb, 12:10, Wolfgang Draxinger <-
    > muenchen.de> wrote:
    >
    >> The standard PRNG that comes with most C standard libraries isn't very
    >> good,

    >
    > odd isn't it? I'm told in another thread that the typical C library
    > is of such high quality that I'd be mad to use anything else. Whilst
    > here I'm told the PRNGs of the typical C library are poor. Is the
    > definition of srand/rand too restrictive?


    The problem is in using words with very little absolute meaning, such as
    "good" and "poor" and trying to derive meaning from the surrounding words.
    One person's good is another persons poor.

    In the case of PRNGs in particular this is compounded by a lot of war
    stories on the subject. I personally experienced one of the bad ones quite
    some time back and it gave me fits in a simulation I was writing. . I don't
    condemn modern cars because of some of the hideous things that happened to
    me over the years with old cars, likewise I don't automatically condemn
    PRNGs.
    osmium, Feb 10, 2010
    #15
  16. johnty

    bartc Guest

    Re: OT: Proper use of PRNGs

    "Eric Sosman" <> wrote in message
    news:hkue30$gbu$-september.org...
    > On 2/10/2010 8:05 AM, Nick Keighley wrote:
    >> On 10 Feb, 12:10, Wolfgang Draxinger<-
    >> muenchen.de> wrote:
    >>
    >>> The standard PRNG that comes with most C standard libraries isn't very
    >>> good,

    >>
    >> odd isn't it? I'm told in another thread that the typical C library
    >> is of such high quality that I'd be mad to use anything else. Whilst
    >> here I'm told the PRNGs of the typical C library are poor. Is the
    >> definition of srand/rand too restrictive?

    >
    > Since the sequence generated by rand() depends entirely
    > on the seed provided by srand(), and since the argument to
    > srand() is an unsigned int, it follows that rand() can produce
    > no more than UINT_MAX+1 different sequences. That could be as
    > few as 65536, or more typically 4294967295.
    >
    > Four billion sequences may sound like a lot, but consider:
    > You can shuffle a deck of fifty-two cards in 52! ~= 8e67 ways,
    > which is 2e58 times four billion


    It's also 2e48 times 18 trillion (that's the old trillion). So even 64-bits
    doesn't 'cut' it.

    What's the answer then, use a 230-bit PRNG?

    --
    Bartc
    bartc, Feb 10, 2010
    #16
  17. Re: OT: Proper use of PRNGs

    bartc wrote:

    > It's also 2e48 times 18 trillion (that's the old trillion). So even
    > 64-bits doesn't 'cut' it.
    >
    > What's the answer then, use a 230-bit PRNG?


    Something like that yes. What you do is concatenating the bits of the
    repeated output of, say a 32 bit PRNG. This introduces some tricky part...

    The quality of a PRNG is measured by its

    * periodicy, that is the number of taken values until it's repeating
    totally. Be aware that there is no /theoretical/ upper limit to this.
    No matter if the numbers generated are 8, 256, 1024 or any other number
    of bits; one may think the single numbers as just being sub-bits of a
    really huge random number being generated, each iteration adding bits.
    In practice every PRNG has a periodicy, determined by its algorithm.

    * Uniformity of output distribution.

    * Clustering (depending on the application one may want strong
    clustering or none at all).

    and

    * dimensionality

    The last part is the tricky one. A PRNG that creates a seemingly good
    looking distribution in a single dimension may show some clear patterns or
    clusters when collating a given number of sequential outputs into a vector.
    The dimensionality of a PRNG is the minimal sequence length/vector dimension
    for patterns/clusters showing up - ideally this would be infinite.

    So far all C standard library PRNGs I encountered were quite limited,
    showing patterns as early as 3 to 5 dimensions.


    Wolfgang
    Wolfgang Draxinger, Feb 10, 2010
    #17
  18. Re: OT: Proper use of PRNGs

    "bartc" <> writes:

    > "Eric Sosman" <> wrote in message
    > news:hkue30$gbu$-september.org...
    >> On 2/10/2010 8:05 AM, Nick Keighley wrote:
    >>> On 10 Feb, 12:10, Wolfgang Draxinger<-
    >>> muenchen.de> wrote:
    >>>
    >>>> The standard PRNG that comes with most C standard libraries isn't very
    >>>> good,
    >>>
    >>> odd isn't it? I'm told in another thread that the typical C library
    >>> is of such high quality that I'd be mad to use anything else. Whilst
    >>> here I'm told the PRNGs of the typical C library are poor. Is the
    >>> definition of srand/rand too restrictive?

    >>
    >> Since the sequence generated by rand() depends entirely
    >> on the seed provided by srand(), and since the argument to
    >> srand() is an unsigned int, it follows that rand() can produce
    >> no more than UINT_MAX+1 different sequences. That could be as
    >> few as 65536, or more typically 4294967295.
    >>
    >> Four billion sequences may sound like a lot, but consider:
    >> You can shuffle a deck of fifty-two cards in 52! ~= 8e67 ways,
    >> which is 2e58 times four billion

    >
    > It's also 2e48 times 18 trillion (that's the old trillion). So even 64-bits
    > doesn't 'cut' it.
    >
    > What's the answer then, use a 230-bit PRNG?


    You may be conflating the number of initial states (and to some extent
    the period) with the number of bits of output. A sequence of numbers
    just 6 bits wide is adequate for shuffling a 52 card deck, but there
    has to be sufficient initial state to be able to seed all (or at least
    a good proportion of) the possible shuffles.

    It is possible to have a 32-bit PRNG with thousands of bytes of state
    and a huge period. Of course, the large state does not always
    correspond to an equally huge set of possible sequences, but the two
    are strongly correlated!

    --
    Ben.
    Ben Bacarisse, Feb 10, 2010
    #18
  19. johnty

    Seebs Guest

    Re: OT: Proper use of PRNGs (was: seg fault in linux but not cygwin)

    On 2010-02-10, Nick Keighley <> wrote:
    > On 10 Feb, 12:10, Wolfgang Draxinger <-
    > muenchen.de> wrote:
    >
    >> The standard PRNG that comes with most C standard libraries isn't very good,

    >
    > odd isn't it? I'm told in another thread that the typical C library
    > is of such high quality that I'd be mad to use anything else. Whilst
    > here I'm told the PRNGs of the typical C library are poor. Is the
    > definition of srand/rand too restrictive?


    Not really. It's just a historical quirk, partially added to by the fact
    that C89's spec was misunderstood by some people to recommend a particularly
    weak PRNG.

    The key is that it's not that you should always use library functions, but
    that you should rarely write your own when they exist. Sometimes you should,
    however, get another library. :)

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    Seebs, Feb 10, 2010
    #19
  20. santosh <> writes:
    > johnty wrote:
    >> i'm facing a rather baffling problem:
    >>
    >> calling a function in a FOR loop. the function has the following
    >> lines:
    >>
    >> clock_gettime(CLOCK_REALTIME, &time_stamp);
    >> srand(time_stamp.tv_nsec);

    >
    > I hope that in your actual code you cast the long value to unsigned in
    > the srand() call above.


    Why? If <time.h> has been #included, the conversion will be done
    implicitly.

    [...]

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Feb 10, 2010
    #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. Corrine
    Replies:
    1
    Views:
    420
    Gianni Mariani
    Nov 27, 2003
  2. goktan
    Replies:
    4
    Views:
    2,022
    Howard
    Aug 2, 2004
  3. Mahendra Kumar Kutare

    Seg Fault - Can not access memory ?

    Mahendra Kumar Kutare, Oct 17, 2007, in forum: C Programming
    Replies:
    0
    Views:
    329
    Mahendra Kumar Kutare
    Oct 17, 2007
  4. Mahendra Kumar Kutare

    Seg Fault - Can not access memory ?

    Mahendra Kumar Kutare, Oct 17, 2007, in forum: C Programming
    Replies:
    0
    Views:
    306
    Mahendra Kumar Kutare
    Oct 17, 2007
  5. Mahendra Kumar Kutare

    Seg Fault - Can not access memory ?

    Mahendra Kumar Kutare, Oct 17, 2007, in forum: C Programming
    Replies:
    7
    Views:
    367
    David Thompson
    Oct 29, 2007
Loading...

Share This Page