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
_______________________________________________ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
