not thread safe?

[p6rt]

Migrated from rt.perl.org#127138 (status was 'open')

Searchable as RT127138$

[p6rt]

From rotwang@crux.org.pl

Hi,

recently when trying to parallelise fetching multiple websites with LWP​::Simple over https (LWP​::Simple utilizes IO​::Socket​::SSL module which in turn uses NativeCall to execute openssl functions from the openssl c library) I've encountered rakudo crashes. Here is golfed version of my issue​:

getenv should be threadsafe according to​: http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_01

# Non parallelised version works as expected​: $ perl6 -e 'use NativeCall; sub getenv(Str) is native returns Str { * }; say getenv("HOME")' /home/ubuntu

# Lets try it parallelised (this time worked)​: $ perl6 -e 'use NativeCall; sub getenv(Str) is native returns Str { * }; await start { getenv("HOME") } xx 2' $ echo $? 0 # More promises bigger chance of hitting the issue​: $ perl6 -e 'use NativeCall; sub getenv(Str) is native returns Str { * }; await start { getenv("HOME") } xx 25' Cannot invoke this object (REPR​: Null)   in block \ at -e line 1

Camelia from freenode​:

21​:07 \ m​: use NativeCall; sub getenv(Str) is native returns Str { * }; await start { getenv("HOME") } xx 5 21​:07 \ rakudo-moar 4bb47d​: OUTPUT«(signal SEGV)»

21​:08 \ m​: use NativeCall; sub getenv(Str) is native returns Str { * }; await start { getenv("HOME") } xx 20 21​:08 \ rakudo-moar 4bb47d​: OUTPUT«Memory allocation failed; could not allocate 21080 bytes␤Memory allocation failed; could not allocate 21080 bytes␤»

21​:09 \ m​: use NativeCall; sub getenv(Str) is native returns Str { * }; await start { getenv("HOME") } xx 15 21​:09 \ rakudo-moar 4bb47d​: OUTPUT«Could not spawn thread​: errorcode -1␤»

Issue doesn't happen every time, so at times it may be hard to reproduce, however increased promises quantity should increase the odds.

[p6rt]

From @lizmat

On 03 Jan 2016, at 21​:20, Bartłomiej Palmowski (via RT) \perl6\-bugs\-followup@​perl\.org wrote​:

# New Ticket Created by Bartłomiej Palmowski # Please include the string​: [perl #​127138] # in the subject line of all future correspondence about this issue. # \<URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=127138 >

Hi,

recently when trying to parallelise fetching multiple websites with LWP​::Simple over https (LWP​::Simple utilizes IO​::Socket​::SSL module which in turn uses NativeCall to execute openssl functions from the openssl c library) I've encountered rakudo crashes. Here is golfed version of my issue​:

getenv should be threadsafe according to​: http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_01

http://pubs.opengroup.org/onlinepubs/9699919799/functions/getenv.html seems to claim otherwise?

"The getenv() function is inherently not thread-safe because it returns a value pointing to static data.”

Liz

[p6rt]

The RT System itself - Status changed from 'new' to 'open'

[p6rt]

From @geekosaur

On Mon, Jan 4, 2016 at 10​:51 AM, Elizabeth Mattijsen \liz@&#8203;dijkmat\.nl wrote​:

getenv should be threadsafe according to​:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_01

http://pubs.opengroup.org/onlinepubs/9699919799/functions/getenv.html

seems to claim otherwise?

"The getenv() function is inherently not thread-safe because it returns a value pointing to static data.”

From the first link claiming that getenv() is thread safe... how are you reading that? I see​:

  "the following functions need not be thread-safe​: (...) getenv()"

Also note below the function list​:

  Since multi-threaded applications are not allowed to use the *environ* variable to access or modify any environment variable while any other thread is concurrently modifying any environment variable, any function dependent on any environment variable is not thread-safe if another thread is modifying the environment

(plus a link to the environment variables documentation which explicitly relates getenv() to `environ`)

-- brandon s allbery kf8nh sine nomine associates allbery.b@​gmail.com ballbery@​sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

[p6rt]

From rotwang@crux.org.pl

I've already corrected myslef (but somehow my second email didn't make it to the bugtracker), so I'll repeat it here​:

Actually getenv isn't thread safe but rakudo shouldn't crash anyway. Here is another example​:

$ cat foo.c #include \<stdio.h>

int foo(void) { return 0; } $ gcc -fPIC -shared foo.c -o foo.so $ perl6 -e 'use NativeCall; sub foo is native("./foo.so") returns int32 { * }; await start { foo } xx 25' $ perl6 -e 'use NativeCall; sub foo is native("./foo.so") returns int32 { * }; await start { foo } xx 25' Cannot invoke this object (REPR​: Null)   in block \ at -e line 1

and here is another​:

01​:03 \< Rotwang> m​: use NativeCall; sub puts(Str) is native returns int32 { * }; await start { puts("dupa") } xx 15 01​:03 \<+camelia> rakudo-moar e95c62​: OUTPUT«(signal SEGV)»

besides even if the function is not thread safe, IMO rakudo shouldn't coredump.

2016-01-04 15​:58 GMT+00​:00 Brandon Allbery via RT \< perl6-bugs-followup@​perl.org>​:

On Mon, Jan 4, 2016 at 10​:51 AM, Elizabeth Mattijsen \liz@&#8203;dijkmat\.nl wrote​:

getenv should be threadsafe according to​:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_01

http://pubs.opengroup.org/onlinepubs/9699919799/functions/getenv.html

seems to claim otherwise?

"The getenv() function is inherently not thread-safe because it returns a value pointing to static data.”

From the first link claiming that getenv() is thread safe... how are you reading that? I see​:

"the following functions need not be thread\-safe​: \(\.\.\.\) getenv\(\)"

Also note below the function list​:

Since multi\-threaded applications are not allowed to use the

*environ* variable to access or modify any environment variable while any other thread is concurrently modifying any environment variable, any function dependent on any environment variable is not thread-safe if another thread is modifying the environment

(plus a link to the environment variables documentation which explicitly relates getenv() to `environ`)

-- brandon s allbery kf8nh sine nomine associates allbery.b@​gmail.com ballbery@​sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net