seg fault in linux but not cygwin

[johnty]

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

 

[Malcolm McLean]

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.

 

[Michael Foukarakis]

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.

 

[santosh]

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?

 

[Nobody]

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.

 

[johnty]

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...

 

[Wolfgang Draxinger]

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

 

[Nick Keighley]

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?

 

[Rob Kendrick]

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.

 

[Ben Bacarisse]

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.

 

[Eric Sosman]

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]

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.

 

[Wolfgang Draxinger]

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

 

[Michael Foukarakis]

     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.

 

[osmium]

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.

 

[bartc]

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?

 

[Wolfgang Draxinger]

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

 

[Ben Bacarisse]

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!

 

[Seebs]

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

 

[Keith Thompson]

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.

[...]