seg fault in linux but not cygwin

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

On Feb 10, 1:34*pm, johnty <johntyw...@gmail.com> 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.

On Feb 10, 1:34*pm, johnty <johntyw...@gmail.com> 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.

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?

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.

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

On 10 Feb, 12:10, Wolfgang Draxinger <Wolfgang.Draxin...@physik.uni-
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?

On Wed, 10 Feb 2010 05:05:13 -0800 (PST)
Nick Keighley <nick_keighley_nospam@hotmail.com> wrote:

> On 10 Feb, 12:10, Wolfgang Draxinger <Wolfgang.Draxin...@physik.uni-
> 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.

johnty <johntywang@gmail.com> 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.

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
esosman@ieee-dot-org.invalid

On 2/10/2010 8:05 AM, Nick Keighley wrote:
> On 10 Feb, 12:10, Wolfgang Draxinger<Wolfgang.Draxin...@physik.uni-
> 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
esosman@ieee-dot-org.invalid

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

On Feb 10, 3:58*pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> On 2/10/2010 8:05 AM, Nick Keighley wrote:
>
> > On 10 Feb, 12:10, Wolfgang Draxinger<Wolfgang.Draxin...@physik.uni-
> > muenchen.de> *wrote:
>
> >> The standard PRNG that comes with most C standard libraries isn't verygood,
>
> > 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.

"Nick Keighley" wrote:

> On 10 Feb, 12:10, Wolfgang Draxinger <Wolfgang.Draxin...@physik.uni-
> 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.