This is the mail archive of the
mailing list for the Cygwin project.
RE: mc segfaults
- From: Pavel Tsekov <ptsekov at gmx dot net>
- To: cygwin at cygwin dot com
- Date: Thu, 5 Jun 2003 16:01:46 +0200 (CEST)
- Subject: RE: mc segfaults
On Thu, 5 Jun 2003, Igor Pechtchanski wrote:
> > >, etc. Do the files
> > >/etc/passwd and /etc/group exist on your system ?
> > Yes, but /etc/passwd is somewhat strange, in that my user
> > id (i.e. what is returned by 'id -u') does not match the
> > respective entry in /etc/passwd:
> > $ id -u
> > 56297
> > $ grep -c 56297 /etc/passwd
> > 0
> > There *is* an entry in /etc/passwd corresponding to my
> > Windows account, but it has user id 121833.
> > Ronald
> Okay, Ronald, you're suffering from the UID wrapping problem. Cygwin UIDs
> are currently 16 bit, so any number higher than 65535 will get wrapped
> (and did). You can change your UID to any unique number smaller than
> 65535 (56297 should do as well as any other). I don't know that that's
> the cause of your mc problem, but it's something to fix nonetheless.
> If it turns out to fix your problem, it's a bug in 'mc', IMO.
See this code:
current_user_uid = getuid ();
pwd = getpwuid (current_user_uid);
g_return_if_fail (pwd != NULL);
It may be regarded as a bug too - but the fact that an assertion is shown
means that the author of the code decided that it is the right thing to
do i.e. it is not a programmering bug. Obiviosly the auhtor thought for
a while and decided that having UID for which a corresponding passwd
struct cannot be retrieved is not a normal situation.
I cannot judge if he was right or not without further inspecting the code -
this particular situation maybe can be avoided by removing the offending
call because there is this comment at its start:
/* This function initialize global GTree with the gids of groups,
to which user belongs. Tree also store corresponding string
with the name of the group.
FIXME: Do we need this names at all? If not, we can simplify
initialization by eliminating g_strdup's.
I have investigate to draw a conclusion though. But then there may be
other places where getpwuid() is called the same way - this means a lot of
work have to be put into finding the places and dealing with each one.
I don't think that I need to do all this now when 64 bit Cygwin is
to be released.
Anyway if you see a clean solution to this problem, one that won't
impact the functionality of the program, I'll be happy to follow any
advice you can give and release an update.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html