View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000521||LDMud 3.5||Runtime||public||2007-10-18 09:23||2011-02-13 22:38|
|Target Version||3.5.0||Fixed in Version||3.5.0|
|Summary||0000521: Overflows in string statistics|
|Description||Sorry for yet another overflow in the statistics. ;-)|
--------------- Strings Bytes (Data+Overhead)
Total asked for 7786294 281646482 (149279484+132366998)
Total allocated 729111 51079496 ( 38422465+ 12657031)
- tabled 616083 43650345 ( 32914790+ 10735555)
- untabled 113028 7429151 ( 5507675+ 1921476)
Space required vs. 'regular C' string implementation: 5% with, 25% without
Searches by address: 161432956 - found: 161432956 (100.0%) - avg length: 1.094
Searches by content: 881756876 - found: 4118127974 (467.0%) - avg length: 0.679
Hash chains used: 65529 of 65536 (100.0%)
Distinct strings added: 162049039 - deleted: 161432956
Collisions: 161224279 (99.5% added)
Equality tests: 2628322655 total, 2946161777 by table (112.1%), 638101843 by
Comparisons: 1917844876 total, 2810187620 by table (146.5%)
Table lookups for existence: 513163480, 109167934 by table (21.3%), 403995546 by content (78.7%)
As you see, there are at least 3 overflows (searches, equality tests and comparisons). Additionally the comparison to C strings seems to be flawed (space required should be less without overhead).
The counters are already p_uint so we probably would have to go the way suggested in 0000520 for solving it (giga-searches etc.).
BTW: This is probably an issue to nearly all the statistics counters for heavily used operations in larger muds, e.g. outgoing traffic in network i/o as well, which is limited to 4GB. (Our uptime is only 24 days until now.)
|Tags||No tags attached.|
Mhmm, wouldn't it be the simplest solution to change these counters (I think, a few more overflowed in the meantime in Morgengrauen) to int64/int64_t/long long? I think, that is less complicated and less expensive at runtime than introducing corresponding giga counters...
Is there any serious disadvantage I do not see at the moment?
I am not sure how to handle this. Actually, I would like to just change these counters to a larger int. That should be mp_uint, but as long as mp_uint is the same size as p_uint, it won't help on ILP32 platforms. That would only change on ILP32 platforms, if we change mp_uint to uintmax_t, which we can't until 0000556 ist resolved.
So, we could wait with this bug until we solved 0000556 and uintmax_t or ulong long or uint64_t on systems which have one. Or we introduce that Gigacounter strategy, but that is more complicated...
||I would use (unsigned) long long int. We need a new typedef in port.h for that, so it can be used also on ILP32 platforms.|
||Erm, right, that means waiting for 0000556.|
||Ok, I will introduce a new typedef statcounter_t with corresponding modifiers for printf in port.h and change all the heavily used stat counters to this type.|
||Resolved in r2626.|
|2007-10-18 09:23||zesstra||New Issue|
|2008-01-26 16:47||zesstra||Note Added: 0000589|
|2008-07-16 18:57||zesstra||Note Added: 0000738|
|2008-07-17 02:24||Gnomi||Note Added: 0000739|
|2008-07-17 02:28||Gnomi||Note Added: 0000740|
|2008-07-17 04:53||zesstra||Status||new => assigned|
|2008-07-17 04:53||zesstra||Assigned To||=> zesstra|
|2009-02-15 09:01||zesstra||Relationship added||related to 0000608|
|2009-06-03 13:58||zesstra||Project||LDMud 3.3 => LDMud 3.5|
|2009-06-03 14:12||zesstra||Note Added: 0001188|
|2009-06-03 16:04||zesstra||Note Added: 0001190|
|2009-06-03 16:04||zesstra||Status||assigned => resolved|
|2009-06-03 16:04||zesstra||Fixed in Version||=> 3.5.0|
|2009-06-03 16:04||zesstra||Resolution||open => fixed|
|2011-02-13 22:38||zesstra||Target Version||=> 3.5.0|