Re: no thread-safe +initialize in old gnustep runtime?

[Nicola Pero]

Sebastian,

it's difficult to say without having looked at the code.  I assume that nobody 
really answered
because they didn't have time to look at the actual code. :-(

Is your problem consistently reproducible ?  If so, it may not be a threading 
problem.  The non-thread-safe
implementation of +initialize can be a problem, but "in the wild" I'd expect 
the bug to occur, or not occur,
randomly, depending on the execution order of the threads (and it should only 
occur the first time a class
is used).

The snippet of code you show below uses NSTask, but I don't see any threads in 
it.  Is it a problem
with NSTask on OpenBSD not correctly detecting when the subprocess terminates, 
or what the
return value is ?

Anyhow, if there are some threads involved somewhere, and you suspect that the 
problem is the non-thread-safe
implementation of +initialize, then you should identify the classes with a 
suspicious +initialize method,
let's say NSObject and NSTask, and add calls such as
  
  [NSObject class]; 
  [NSTask class];

before you go multi-threaded (eg, in main()).  These calls do nothing, but 
trigger the +initialize.  If you trigger
it before starting any additional threads, you work around the 
"multi-threading" problem with +initialize.  Does
the problem disappear if you do this (with the correct classes there) ?  If so, 
it may well be the unsafe +initialize
bug.

I hope this helps. :-)

Thanks

On 6 Jun 2011, at 17:50, Sebastian Reitenbach wrote:

> Hi,
> 
> since I experienced some strange behaviour with Burn on OpenBSD, when the 
> application starts to get multi-threaded, I installed the old gnustep 
> runtime, since with the new libobjc2 runtime I get those random crashers....
> I thought the old runtime should be fine enough, since I got those message 
> when the program got multi-threaded:
> 
> WARNING your program is becoming multi-threaded, but you are using an 
> ObjectiveC runtime library which does not have a thread-safe implementation 
> of the +initialize me
> thod.  This means that any classes not already used may be incorrectly 
> initialised, potentially causing strange behaviors and crashes.\nTo put this 
> into context, the runtime bug has been knoown
> for several years and only rarely causes problems ... the easy workaround 
> being to ensure that any classes used by a new thread have already been used 
> in the main thread before the new thread
> starts.\nIf you are worried, please build/run GNUstep with a runtime which 
> supports the +initialize method. The GNUstep stable runtime (libobjc) and 
> experimental runtime (libobjc2), available f
> rom the GNUstep website and subversion repository, should both work.\nTo 
> disable this warning (eg. for an application which does not suffer any 
> problems caused by this runtime bug), please set
> the GSSilenceInitializeWarning user default to YES.
> 
> However, after installing libobjc-1.6.1, and recompiling gnustep-base, I 
> found that the above warning still shows up. Taking a look in the config.log 
> I found those lines which I think are the relevant lines:
> 
> 
> from config.log
> configure:7098: checking for thread-safe +initialize in runtime
> configure:7110: cc -o conftest -O2 -pipe -g  -I/usr/local/include 
> -I/usr/local/include -I/usr/local/include -I/usr/local/include -fgnu-runtime 
> -x objective-c  -L/usr/local/lib -L/usr/local/lib
> -L/usr/local/lib -L/usr/local/lib conftest.c  -lpthread -lobjc   -pthread  >&5
> In file included from ./config/config.initialize.m:4,
>                 from conftest.c:98:
> ./config/objc-common.g:22: warning: cannot find interface declaration for 
> 'NXConstantString'
> ./config/objc-common.g: In function '+[NSObject new]':
> ./config/objc-common.g:44: warning: incompatible implicit declaration of 
> built-in function 'calloc'
> /usr/local/lib/libobjc.so.0.0: warning: strcpy() is almost always misused, 
> please use strlcpy()
> /usr/local/lib/libobjc.so.0.0: warning: sprintf() is often misused, please 
> use snprintf()
> configure:7110: $? = 0
> configure:7110: ./conftest
> class entered prematurely
> configure:7110: $? = 1
> configure: program exited with status 1
> configure: failed program was:
> ...
> 
> So I wonder whether I need to do sth. additionally? I used gnustep-make 1.6.0 
> and gnustep-base-1.22.0.
> 
> The actual problem I observed with Burn is that it starts an NSTask, it may 
> or may not recognize whether it ended, i.e. for example when I try to create 
> an ISO image:
>        mkiTask = [[NSTask alloc] init];
>        stdOut = [[NSPipe alloc] init];
> 
>        mkiArgs = [self makeParamsForVolumeId: volumeId
>                                                                fileList: 
> trackArray
>                                 outFile: outFile
>                          withParameters: parameters];
> 
>        [mkiTask setLaunchPath: mkisofs];
>        [mkiTask setArguments: mkiArgs];
>        [mkiTask setStandardError: stdOut];
> 
>        [self sendOutputString: [NSString stringWithFormat: _(@"Launching %@ 
> %@"),
>                                                                               
>          mkisofs, [mkiArgs componentsJoinedByString: @" "]] raw: NO];
> 
>        [mkiTask launch];
> 
>        /*
>         * Now we wait until the mkisofs task is over and process its output.
>         */
>        [self waitForEndOfTask];
> NSLog(@"waited for the end of the task");
>        /*
>         * If mkisofs did not terminate gracefully we stop the whole affair.
>         * We delete in any case the actual (not finished) file.
>         */
>        termStatus = [mkiTask terminationStatus];       // FreeBSD needs an 
> lvalue for the WIF* macros
> 
> 
> I may be lucky and I see the NSLog statement, but when I close Burn, and try 
> again, it may not work. Burn has a console where I can see the output of 
> external programs like mkisofs. In the console I can always see that the 
> creation of the ISO worked well, since the output is shown in that console 
> window.
> 
> 
> Sebastian
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep