FWIW, I can't reproduce your bug. What level of scsh & what OS are
you on?
eg,
lambda$ scsh
Scsh 0.4
> (user-info "sjenkins")
'#{user-info "sjenkins"}
> (user-info "noone")
Error: Cannot get user's information
#{Procedure 8656 name->user-info}
"noone"
1>
>Since I don't 100% understand how CIG is supposed to work, I don't know the
>right way to fix this. The symptom:
>
> curry:alan> scsh
> Scsh 0.4
> > (user-info "alan")
> '#{user-info "alan"}
> > (user-info "UnKnOwN")
> Segmentation fault
> curry:alan>
>
>The problem is that the the code generated by CIG for `%name->user-info'
>allocates a bunch of variables and passes the addresses of those variables
>in to user_info_name(). user_info_name() looks like this:
>
> int user_info_name(const char *name,
> uid_t *uid, gid_t *gid, char **dir, char **shell)
> {
> struct passwd *pwd = getpwnam(name);
> if( !pwd ) return 0;
> *uid = pwd->pw_uid;
> *gid = pwd->pw_gid;
> *dir = pwd->pw_dir;
> *shell = pwd->pw_shell;
> return 1;
> }
>
>Notice that if getpwnam() returns NULL, then nothing is done with those
>variable addresses. So the variables are still uninitialized. Next, the
>CIG generated code attempts to convert those C values into Scheme48 values.
>Since the C value is ininitialized garbage, this conversion sometimes
>generates a segmentation fault.
It's actually more like: the 'main' return value is a boolean (ie, 'win?').
If you 'lose', the contents are invalid, but you never poke at them, as an
error is raised.
>
>I would -guess- that the fix is to re-write all those routines in
>`userinfo1.c'. Although perhaps the answer is for CIG to initialize such
>variables with reasonable initial C values.
>
>If the fix is the former, I'll fix it myself and send you the patch. Let
>me know...
>
>Seems like this is the kind of error that might be lurking in a lot of
>places. Someone might want to browse through the code looking for other
>instances.
Steven L. Jenkins
|