bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

NSProcessInfo.m: Problem with **LONG** commandline on linux


From: Roland Schwingel
Subject: NSProcessInfo.m: Problem with **LONG** commandline on linux
Date: Fri, 01 Aug 2003 10:32:45 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312

Hi...

Last night I ran into a problem with NSProcessInfo.m (from 1.7.2) on linux which caused GNUstep to crash... It happened to me to get a 4561 Bytes long commandline to run a tool (toolname + 43 Arguments)... Ok I know this isnt very common but maybe NSProcessInfo shouldn't crash handling it. What exactly happens is still a bit mysterious... But when entering _gnu_process_args() (called by +[NSProcessInfo initialize] there is at present a check

 if (argv != 0)
   {
         _gnu_arg_zero = (char*)malloc(strlen(argv[0]) + 1);
         strcpy(_gnu_arg_zero, argv[0]);
   }
 else
  ....

Well in my case argv was a pointer but argv[0] was NULL, so strlen() crashes...I changed it to look that way

 if (argv != 0)
   {
       if (argv[0] != NULL)
       {
         _gnu_arg_zero = (char*)malloc(strlen(argv[0]) + 1);
         strcpy(_gnu_arg_zero, argv[0]);
     }
   }
 else
  ....

Afterwards everything runs fine (for my tool, because it handles argv,argc directly in main() where argv and argc are correct, not needing NSProcessInfo for it)... So adding this check here might not be that wrong, but the real reason for being _gnu_noobjc_argc, _gnu_noobjc_argv bogus (set in +load from procfs) has to be invesitigated to get it really working with linux as well... I can reproduce this everytime. The commandline needn't be exactly that size can also be smaller for the bug to appear on my side (SUSE 8.0, kernel 2.4.20, glibc 2.2.5,gnustep-base 1.7.2.,gnustep-objc 1.3.0,gcc 3.2.2)

Maybe adding at least this tiny if(argv[0] != NULL) can IMHO not harm....

Roland






reply via email to

[Prev in Thread] Current Thread [Next in Thread]