This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [BUG] pututline () & rxvt: rxvt leaves stale utmp entries

On Tue, Aug 05, 2003 at 01:45:48AM +0200, Pavel Tsekov wrote:

Hi Pavel, nice to see a message from you.

>On rxvt startup two utmp entries are created - the first one is created by
>Cygwin and the second one is created by rxvt itself:
>$ who
>Administ tty1         Aug  5 01:26 (MORDOR)
>Administ tty2         Aug  5 01:26 (:0)
>After rxvt shutdown:
>$ who
>Administ tty2         Aug  5 01:26 (:0)
>The cause for this seems to be that rxvt assumes that the return value
>of getutid () is usable in a call to pututline (), which doesn't seem
>to hold true on Cygwin.  It turns out that Cygwin uses the same static
>variable to return utmp entries to the caller and also for its own
>internal purposes i.e.  searching for the right utmp entry.  I don't
>know if Cygwin is right or not in this case, and there doesn't seem to
>be a lot of documentation on this topic.  The linux man pages tells
>that the return value of getutid(), getutline() and getutent() is a
>static memory but doesn't say anything about what could possibly happen
>if one uses it back in a call to pututline().  So I guess the behaviour
>is pretty much undefined.  On the other hand there is a comment in the
>Cygwin source of logout() which indicates that the author of putline ()
>was aware of this behaviour so I draw the conclusion that it is not a
>bug in Cygwin:
>       /* We can't use ut further since it's a pointer to the static utmp_data
>        area (see below) and would get overwritten in pututline().  So we
>        copy it back to the local ut_buf. */
>I've created a simple testcase (attached) which when ran on Linux
>produces the results that rxvt expects.  Unfortunately currently I do
>not have access to any other unices on which I can run the testcase.

A simple test case.  Sob.  A simple test case.  Oh, how I've missed you.

Given the good problem description and the simple test case, this shouldn't
be hard to fix.  I'll see what I can do.  The behavior that you've described
has bugged me for a while.  I'm glad that you tracked down what was going on.


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]