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

[Sebastian Reitenbach]

On Wednesday, June 8, 2011 19:41 CEST, Nicola Pero 
<nicola.pero@meta-innovation.com> wrote: 
 
> 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, I was only guessing so far, whether the problem really is regarding the 
threading, I'll see, it was the only obvious thing I observed so far, which 
might be related, or not ;)

Sebastian



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