View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000607 | LDMud 3.3 | Runtime | public | 2009-02-12 16:33 | 2011-02-23 22:22 |
Reporter | peng | Assigned To | zesstra | ||
Priority | normal | Severity | minor | Reproducibility | N/A |
Status | resolved | Resolution | fixed | ||
Product Version | 3.3.718 | ||||
Target Version | 3.3.720 | Fixed in Version | 3.3.720 | ||
Summary | 0000607: check_alarm triggers because alarm is off | ||||
Description | In FinalFrontier the driver has ramdomly problems with the alarm call. approx. 3-5 times a day the alarm is off and the check_alarm-fun in backend.c has to restart it. This causes 16 sec. without HB in the mud, which disturbes the players while fighting and such. | ||||
Additional Information | In a driver-version which replaced the alarm()-calls with setitimer(), the prob doesn't occurred any longer. Additional debug in check_alarm() shows, that the alarm is of and not just delayed. | ||||
Tags | No tags attached. | ||||
Attached Files | setitimer-backend.c.patch (2,602 bytes)
Index: backend.c =================================================================== --- backend.c (revision 2486) +++ backend.c (working copy) @@ -423,6 +423,12 @@ * cleanup doesn't always remove enough destructed objects. */ + struct itimerval timer_value; + timer_value.it_interval.tv_sec = alarm_time; + timer_value.it_interval.tv_usec = 0; + timer_value.it_value.tv_sec = alarm_time; + timer_value.it_value.tv_usec = 0; + /* * Set up. */ @@ -438,7 +444,11 @@ current_time = get_current_time(); comm_time_to_call_heart_beat = MY_FALSE; time_to_call_heart_beat = MY_FALSE; - alarm(alarm_time); +// alarm(alarm_time); + if(setitimer( ITIMER_REAL, &timer_value, NULL )) { + fatal("Could not initialize the timer, errno %d.\n", + errno); + } } printf("%s LDMud ready for users.\n", time_stamp()); @@ -709,7 +719,7 @@ /* Start the next alarm */ comm_time_to_call_heart_beat = MY_FALSE; time_to_call_heart_beat = MY_FALSE; - alarm(alarm_time); + //alarm(alarm_time); /* Do the timed events */ if (!synch_heart_beats @@ -793,7 +803,12 @@ { static mp_int last_alarm_time = 0; mp_int curtime = get_current_time(); + struct itimerval timer_value; + timer_value.it_interval.tv_sec = alarm_time; + timer_value.it_interval.tv_usec = 0; + timer_value.it_value.tv_usec = 0; + if (t_flag) /* Timing turned off? */ return; @@ -811,11 +826,18 @@ "- restarting it.\n", time_stamp(), curtime - last_alarm_time); - alarm(0); /* stop alarm in case it is still alive, but just slow */ + //alarm(0); /* stop alarm in case it is still alive, but just slow */ + timer_value.it_value.tv_sec = 0; + setitimer( ITIMER_REAL, &timer_value, NULL ); comm_time_to_call_heart_beat = MY_TRUE; time_to_call_heart_beat = MY_TRUE; (void)signal(SIGALRM, (RETSIGTYPE(*)(int))catch_alarm); - alarm(alarm_time); + //alarm(alarm_time); + timer_value.it_value.tv_sec = alarm_time; + if(setitimer( ITIMER_REAL, &timer_value, NULL )) { + fatal("Could not initialize the timer, errno %d.\n", + errno); + } last_alarm_time = curtime; /* Since we just restarted it */ } | ||||
|
This is the before mentioned patch for setitimer. It just replaces the alarm-call in the startup with setitimer with auto-restart, so this is basically the same as restarting the alarm in catch_alarm instead of the way down in the backend cycle. The changes in check_alarm are straight forward, but check_alarm never triggered with this version. |
|
Exchanging alarm() by setitimer() seems to me a reasonable idea, because it is simpler (at least in theory). But we should nevertheless find out, whats going wrong there. So far nobody else reported such problems, but you can reproduce it on two different machines (as far as I understood). So we may try to find similarities between them which are otherwise rare. If you can think of anything which is common for your 2 systems or sets them apart from other systems, that would be great of course... ;-) Could you give us information about hard- and software of the 2 machines? e.g. platform, versions of kernel, glibc, other libaries the driver uses, maybe 'uname -a', driver settings (config.h, machine.h). Is there a (basic) public variant of the mudlib you use which we may use? Or if not, can you test a different mudlib? ;-) Other than that it seems we would have to scatter a bunch of debug messages with the current status of alarm() all over the code in comm.c/backend.c or does anyone think of a simpler approach? |
|
Gnomi and me just discussed, that we both don't like to change code in response to a problem if we don't know the root cause of the problem. And because we have no information which might help us to reproduce the issue and we did not experience anything like this, I am inclined to close this as 'unable to reproduce'. If you have any further information which might help, please provide them. |
|
I reworked the signal handling between r2872 - r2882 (3.5) and among other things I switched the alarm timer to ITIMER_REAL. However, this series of changes is in 3.5. for the time being, because it is in sum a larger change and I would not apply it to 3.3.x without a longer test phase. |
|
Just taking this for the time being - until I am confident enough for porting this to 3.3.x |
|
I backported my patches for migration to sigaction() + setitimer() and the better sychronization between host and mud-internal time from 3.5 in r2923-r2926. It is a pity that we could not reproduce the issue here, but I hope that will solve it then and sigaction() and setitimer() are anyway more convenient. Please report back if not. |
Date Modified | Username | Field | Change |
---|---|---|---|
2009-02-12 16:33 | peng | New Issue | |
2009-02-13 10:08 | peng | File Added: setitimer-backend.c.patch | |
2009-02-13 10:11 | peng | Note Added: 0000950 | |
2009-02-13 16:17 | zesstra | Note Added: 0000952 | |
2009-04-09 08:32 | zesstra | Status | new => feedback |
2009-05-26 03:48 | zesstra | Note Added: 0001160 | |
2010-02-19 15:45 | zesstra | Note Added: 0001743 | |
2010-03-14 17:25 | zesstra | Note Added: 0001802 | |
2010-03-14 17:25 | zesstra | Assigned To | => zesstra |
2010-03-14 17:25 | zesstra | Status | feedback => assigned |
2010-07-13 16:04 | zesstra | Note Added: 0001876 | |
2010-07-13 16:04 | zesstra | Status | assigned => resolved |
2010-07-13 16:04 | zesstra | Fixed in Version | => 3.3.720 |
2010-07-13 16:04 | zesstra | Resolution | open => fixed |
2011-02-23 22:22 | zesstra | Target Version | => 3.3.720 |