Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
tintin++ ogg sound player script for linux
Author: Robert Smith
Submitted by: Vladaar
6Dragons ogg Soundpack
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.4
Author: Vladaar
Submitted by: Vladaar
LoP 1.46
Author: Remcon
Submitted by: Remcon
LOP 1.45
Author: Remcon
Submitted by: Remcon
Users Online
CommonCrawl, Sogou, Bing

Members: 0
Guests: 7
Stats
Files
Topics
Posts
Members
Newest Member
481
3,740
19,396
629
DarrenPayn
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » General » Coding » Bug message question
Forum Rules | Mark all | Recent Posts

Bug message question
< Newer Topic :: Older Topic > Specific bug message question

Pages:<< prev 1 next >>
Post is unread #1 Mar 6, 2003, 6:32 am
Go to the top of the page
Go to the bottom of the page

Olcerin

GroupMembers
Posts30
JoinedMar 6, 2003

I installed some code that one of this forum's member's wrote and so far have had no trouble with it except one. This bug message:
Log: [*****] BUG: ALARM CLOCK! In section new_descriptor: after accept
What this post is about is, I'm a noob coder (if it's not obvious) and was wondering what are some possible causes for that lag alarm bug message written into the SMAUG code to activate? (don't reply "lag" please hehe)
To avoid being too vague, what the code does is add the old function that allows sending color to a descriptor so I can have color on the greeting. Nopey flavor.
If no one replies no problem I'll probably figure it out, just figured there was probably enough code knowledge roaming around to find out here.
       
Post is unread #2 Mar 7, 2003, 12:01 am
Go to the top of the page
Go to the bottom of the page

Guest - (Unregistered)

I installed some code that one of this forum's member's wrote and so far have had no trouble with it except one. This bug message:

Log: [*****] BUG: ALARM CLOCK! In section new_descriptor: after accept
What this post is about is, I'm a noob coder (if it's not obvious) and was wondering what are some possible causes for that lag alarm bug message written into the SMAUG code to activate? (don't reply "lag" please hehe)
To avoid being too vague, what the code does is add the old function that allows sending color to a descriptor so I can have color on the greeting. Nopey flavor.

If no one replies no problem I'll probably figure it out, just figured there was probably enough code knowledge roaming around to find out here.


I dunno how much you understand whats going on here, but heres an overview that may indicate the problem or at least attempt to help... I'm afriad I'm not fully up on the Smaugish code, I tend to be a bit more generic ;)

Anywho, some background first.

The alarm is simply where a SIGALRM is raised and caught using signal handlers. There is a function called alarm() in unistd.h that allows you to define a number of seconds to count down from and once that time period is up, the alarm signal is raised. Using signal() from signal.h you can assign a custom handler to specific signals, Smaug attaches its custom alarm handler to the SIGALRM and sets the timer in the main game_loop (or at least somewhere which happens regullary). If you DON'T reach the next alarm call in the loop it never resets, the alarm goes off and the signal fires logding a bug saying its lagging. This means whatever section it indicates its in is taking essentially, too long. A common cause of this can be DNS reverse lookups while ppl login without a seperate DNS slave process, as some DNS lookups can take time, or simply require time to timeout.

In essence, the whole process of accepting a new_descriptor (after accept) it appears is taking too long, you can find out how long it has by taking a look for the alarm() function call in your game_loop, (it might be a setitimer call though, depending on what the author was intending and which type of clock they wanted to use)

A word of warning, you may have noticed where its setting the char* that its using to output in that alarm clock bug report, the fewer of those there are, the less accurate any bug report will be on where the problem is occuring (as it just tells you where the alarm went off, anything before it after the last alarm() call could have caused the slow down really). Its possible all the colour parsing is causing it to slow down, but somehow I very much doubt it, unless you are talking a HUGE amount of text, processing a text string to insert ANSI sequences isn't exactly taxing and time comsuming (although admittedly I don't know the granularity on the alarm periods you have, or even the ones Smaug has), but you may want to take a look at how long it takes to accept a new connection.

I could suggest use of some profiling tools (like gprof from the GNU kit) and/or strace to look at the system calls so you can see exactly whats going on, but I'm not very experienced in the use of them yet, so I'm not entirely sure if they'd help or hinder at this stage

Hopefully that helps, oh and one other point, Network Lag has NOTHING to do with this, select() it is intelligent enough to know if a input/output action will block and thats the point of having the fd_sets pass through it, if there is nothing on the socket, then there is nothing on the socket, its not like you have to wait for it to do stuff, thats what the system/OS/kernel does underneath you
       
Post is unread #3 Mar 7, 2003, 6:25 am
Go to the top of the page
Go to the bottom of the page

Olcerin

GroupMembers
Posts30
JoinedMar 6, 2003

Hey, thanks alot. Believe it or not, I do understand most of what you just said too. I've looked at comm.c so much from SMAUG I've got line numbers memorized to goto functions lol, so I did at least realize the Alarm clock related in some way to the sockets, but just starting into coding the end of last year, that's well out of my league. So, your discussion on SIGALRM has filled in a big void for me, at least on what those entires purpose is in being there.

thx for your time
       
Post is unread #4 Mar 7, 2003, 6:30 am
Go to the top of the page
Go to the bottom of the page

Olcerin

GroupMembers
Posts30
JoinedMar 6, 2003

Well.....I did learn Pascal 18 years ago. Oh, oh and TIBasic too! So, I'm not really a newbie! Just a newbie to any language with any practical use :P haha

**jigs**

(Sorry no more rants out of me, just got off a 10 hour shift overnight, I'm going back to my cage now.)
       
Post is unread #5 Mar 7, 2003, 6:51 am
Go to the top of the page
Go to the bottom of the page

Guest - (Unregistered)

Well.....I did learn Pascal 18 years ago. Oh, oh and TIBasic too! So, I'm not really a newbie! Just a newbie to any language with any practical use :P haha
**jigs**
(Sorry no more rants out of me, just got off a 10 hour shift overnight, I'm going back to my cage now.)

Bah... Delphi is still in reasonable use out there as a RAD IDE afaik, thats just Pascal with a nice front end on it... Pascal isn't that redundant... Algol on the other hand... ;)
       
Post is unread #6 Mar 11, 2003, 11:29 am
Go to the top of the page
Go to the bottom of the page

Eminorik

GroupMembers
Posts17
JoinedJan 30, 2003

TI Basic, no practical use? NOOOOOOoooooo!
       
Pages:<< prev 1 next >>