Re: Bug#323811: libc6: initstate_r segfaults
>There appears to be a problem with the reentrant version of the
I'm currently seeing the same problem with pretty much the same test
code. Strangely, it only happens when compiling with gcc-4.1 (not with
>int main(int argc, char**argv)
> struct random_data rand_data;
> char rand_state;
> // this fixes the segfault:
> // rand_data.state = (int32_t*)rand_state;
> initstate_r(time(0), rand_state, sizeof(rand_state), &rand_data);
>Program received signal SIGSEGV, Segmentation fault.
>0xb7e9d601 in __initstate_r (seed=1124379248, arg_state=0xbf889edc "",
>n=256, buf=0xbf889fdc) at random_r.c:254
>In line 254, __initstate_r tries to set rand_data.state[-1], which
>obviously fails, since rand_data is not initialised yet. The comment
>claims that the function returns a pointer to the old state. This is
>bogus, as the reentrant versions don't act on a global state and the
>function has a return type of int.
>Reading stdlib/random.c shows, that __initstate_r is designed to work with
>an _already_initialised_ rand_state.
This quoted email was sent more than 4 months ago and I'm still seeing the
problem on a fresh debian unstable system (libc6-2.3.5).
So... am I doing something wrong or is this still not fixed?
Also, the info-documentation of libc/initstate_r() needs fixing.
I's just a "does the same as initstate()" blah-blah and nowhere is
explained how the random_data buffer should be set up in the first
place. Since, obviously, initstate_r() assumes to see some valid
pointer values in random_data...
10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse für Mail, Message, More +++