Re: [LONG]Strange Loop

From: George Greer (
Date: 05/20/00

On Sat, 20 May 2000, Benjamin Draper wrote:

> Yup, I see that, but where would the bug be? I've eliminated it being a
>problem with anything I've added by using bpl11, bpl12, bpl16 and bpl17
>*stock* code. This just suddenly 'happened' on Wednesday, and only
>occured once before and the solution was to reboot the machine.

What kernel and operating system?

Did you compile the source code as anything other than Linux or BSD code?

> from the man page for 'select':
>> int  select(int  n,  fd_set  *readfds,  fd_set  *writefds, fd_set
>> *exceptfds, struct timeval *timeout);
>> ...
>> This causes problems ... when code is ported to Linux that reuses
>> a struct timeval for multiple selects in a loop without
>> reinitializing it.  Consider timeout to be undefined after select
>> returns.


#define PER_MASK                (0x00ff)
#define PER_LINUX               (0x0000)
#define PER_LINUX_32BIT         (0x0000 | ADDR_LIMIT_32BIT)
#define PER_SVR4                (0x0001 | STICKY_TIMEOUTS)
#define PER_SVR3                (0x0002 | STICKY_TIMEOUTS)
#define PER_SCOSVR3             (0x0003 | STICKY_TIMEOUTS | WHOLE_SECONDS)
#define PER_WYSEV386            (0x0004 | STICKY_TIMEOUTS)
#define PER_ISCR4               (0x0005 | STICKY_TIMEOUTS)
#define PER_BSD                 (0x0006)
#define PER_XENIX               (0x0007 | STICKY_TIMEOUTS)
#define PER_LINUX32             (0x0008)
#define PER_IRIX32              (0x0009 | STICKY_TIMEOUTS) /* IRIX5 32-bit */
#define PER_IRIXN32             (0x000a | STICKY_TIMEOUTS) /* IRIX6 new 32-bit */
#define PER_IRIX64              (0x000b | STICKY_TIMEOUTS) /* IRIX6 64-bit */

STICKY_TIMEOUTS will not modify the timeout parameter.  So if you compile
it for BSD or Linux, you will probably get it modified.

> As you said in your first reply, if select returns an error, null_time
>could become undefined, so is using null_time in this way a bad thing?
>Or is my MUD host the problem? I can put in a throwaway timeval struct,
>setup like null_time, so null_time isn't trashed, but is this the right
>way to go about it?

By looking at the kernel code, if given 0/0 for timeout, you should get 0/0
back anyway.  So the above may not matter, or you have memory corruption
somewhere that is getting lucky.

George Greer

     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     |  |

This archive was generated by hypermail 2b30 : 04/10/01 PDT