View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001797 | unreal | documentation | public | 2004-05-08 11:39 | 2004-05-08 14:43 |
| Reporter | maniac | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | open | ||
| Product Version | 3.2 | ||||
| Summary | 0001797: -tampachat.webchatting.com- *** Notice -- *** TROUBLE: [BUG] int_to_base64() called for insane value 2147483647. Please report! | ||||
| Description | repeats this message about once every 5 sec to ircops...very annoying... -tampachat.webchatting.com- *** Notice -- *** TROUBLE: [BUG] int_to_base64() called for insane value 2147483647. Please report! *** | ||||
| Steps To Reproduce | log on then /oper | ||||
| 3rd party modules | |||||
|
|
actually, it's not throttled nor monotonic. I'm having the same problem on this network, with another ircd I just fresh-compiled. uname -a reports: Linux hostnamehere 2.4.25 #1 compiledatehere i686 i686 i386 GNU/Linux This is RedHat 9 (Shrike) according to /etc/issue Don't know about tampachat's. |
|
|
Interresting. Let me explain what it is and why I added it: The base64 routines are mainly used for timestamps (but also for server numerics), if the value is over 2147483646 it will give this warning... FYI, a timestamp value of '2147483647' is 'Tue Jan 19 04:14:07 2038' (in GMT+2), so this is very unlikely to ever be correct. Now why I added this? It seemed that in some cases insane values like on opteron/ia64 could get very large (since longs are 64bit at that) it could cause a buffer overflow [underflow, actually] -> memory corruption => crashes... BUT... 2147483647 is just ok, 2147483648 (cannot be reached with 32bits longs) or above gives problems... I guess I'll just modify it so you guys won't get these annoying 'false positives', but ofcoz I still wonder why it would ever get called with a timestamp in the year 2038 ;). |
|
|
i thought it was related to a corrupted ircd.tune, but it appears not (since it sitll happens, tho I fixed the desync bug I was encountering) |
|
|
Fixed in CVS (.2234.2.6). Checks now if a value is >2147483647 (which is only possible on 64 bit archs), if so it will abort(). |
