View Issue Details

IDProjectCategoryView StatusLast Update
0000622LDMud 3.3Runtimepublic2009-05-11 03:55
Reportergarapol Assigned ToGnomi  
PrioritynormalSeveritycrashReproducibilityhave not tried
Status resolvedResolutionfixed 
Product Version3.3.717 
Fixed in Version3.3.719 
Summary0000622: GeoLiteCity as big switch-blocks crashes on high usage
DescriptionI crashed avalon while trying some code for the usage of GeoLiteCity.
I converted the csv file to 324 files (many very small, many around 250 KB code). There is one "central" master, which is called.
Each of theese 324 files is a big switch-case block, having up to 5000 cases.
For some IP-Address (x,y,z,w) to lookup the master calls the file x.c, which may call x_2.c and so on.

I crashed avalon by a stress test, where I got all IP addresses of any logged in user (around 35) and tryed to ask the master where they came from.

Additional InformationThe exact code, which crashes was:
zlpc map(map(map(users(), (: ({$1})+explode(query_ip_number($1), ".") :)), (: ({$1[0], "/w/garapol/temp_neu/GeoLiteCity"->query_town($1[1],$1[2],$1[3],$1[4],1) }) :)), (: tell_object(OBJ(garapol), $1[0]->query_name()+"\t -> " + $2) :))

I have only added some examples of ranges, because I got some Mantis error on uploading the big files...
If you need all files, compile and start the in the directory both GeoLiteCity.csv and iso_country_names.txt are.

For the crash-code I am sure the problem may be, the compiler have too much to do (or load) on a second... but I am not sure.
TagsNo tags attached.


child of 0000705 closedGnomi LDMud 3.2 Backports of 3.3 fixes for 3.2.17 


2009-04-08 19:10 (67,332 bytes)


2009-04-08 19:12

reporter   ~0001014

Sorry, I got some internal server errors (0000401) of Mantis and tryed again and again... this time it worked and added the file...
Please delete the other issues.


2009-04-09 03:06

manager   ~0001015

What messages were on stdout or in the debug.log prior to the crash?
Do you have a backtrace ('gdb <ldmud binary> <core dump file>' and there 'bt f')?


2009-04-09 03:10

manager   ~0001016

There is btw a mistake in the zlpc command. The arguments to query_town() are strings (results from explode()), but query_town() expects ints.


2009-04-09 10:17

administrator   ~0001017

Gnomi found one problem with very large switches. A jump offset was wrongly calculated due to a signed/unsigned short confusion. He committed a fix in r2540 in the trunk.
I guess, any further investigation relies on the debug log and a core dump (or at least stack trace).

The best approach would be to reproduce the problem with 717 in some testmud and then try the current trunk.
I quickly tried the code generator, but it aborted due to some missing class. As I don't want to spend time on working on meta-problems I would appreciate if you make the complete code/testcase available for download or send it bzip2-compressed by mail to me (lets exchange mail addresses via Intermud).


2009-04-09 11:03

manager   ~0001018

I managed to run the generator after downloading the csv database from

I have not been able to make it crash though (tried with 3.3.717 and a relatively recent svn version, without Gnomis patch). Things I tried:

xlpc for (; get_eval_cost() > 100000; ) "/players/fuchur/geolite/GeoLiteCity"->query_town(random(256), random(256), random(256), random(256), 1);

xlpc for (int i = 0; i < 256; i++) "/players/fuchur/geolite/GeoLiteCity"->query_town("" + i, "" + random(256), "" + random(256), "" + random(256), 1);

(I tried the provided crashing command as well, but there was only one user, coming from, so unsurprisingly it didn't do much.)


2009-04-12 17:29

reporter   ~0001021

Last lines of Debug-Log of Avalon (tail):
It really seems to be that signed/unsigned thing.

2009.04.08 20:13:47 Bad stack after evaluation.
sp: 8151590 minimum expected: 8151598
Instruction 53(!=), num arg -1
2009.04.08 20:13:47 Current object was w/garapol/temp_neu/GeoLiteCity84
2009.04.08 20:13:47 Dump of the call chain:
2009.04.08 20:13:47 get_line_number(): Illegal offset -15079 in object w/garapol/temp_neu/GeoLiteCity84.c
' z_lpc' in 'i/zepter/zepter.c (/i/zepter/' (' obj/zepter#955457') line 359
' start_lpc' in 'i/zepter/zepter.c (/i/zepter/' (' obj/zepter#955457') line 269
' fun' in ' w/garapol/LPC_zst.c' (' w/garapol/LPC_zst') line 10
'__inline_w_garapol_LPC_zst_c_10_#0001' in ' w/garapol/LPC_zst.c' (' w/garapol/LPC_zst') line 10
' query_town' in 'w/garapol/temp_neu/GeoLiteCity.c' ('w/garapol/temp_neu/GeoLiteCity') line 69
'query_geocity_town' in 'w/garapol/temp_neu/GeoLiteCity.c' ('w/garapol/temp_neu/GeoLiteCity') line 48
' query_town' in ' UNDEFINED' ('w/garapol/temp_neu/GeoLiteCity84') line 0


2009-05-10 17:30

administrator   ~0001095

Can we assume, that was fixed by Gnomis change? Or is there any new information?


2009-05-11 02:14

reporter   ~0001100

Avalon uses another system, but I am sure Gnomi found the bug. But I did not try.


2009-05-11 03:53

administrator   ~0001101

Apparently fixed by Gnomi in r2540.

Issue History

Date Modified Username Field Change
2009-04-08 19:10 garapol New Issue
2009-04-08 19:10 garapol File Added:
2009-04-08 19:12 garapol Note Added: 0001014
2009-04-09 03:06 Gnomi Note Added: 0001015
2009-04-09 03:10 Gnomi Note Added: 0001016
2009-04-09 10:17 zesstra Note Added: 0001017
2009-04-09 11:03 fufu Note Added: 0001018
2009-04-12 17:29 garapol Note Added: 0001021
2009-05-10 17:30 zesstra Note Added: 0001095
2009-05-10 17:30 zesstra Status new => feedback
2009-05-11 02:14 garapol Note Added: 0001100
2009-05-11 03:53 zesstra Note Added: 0001101
2009-05-11 03:53 zesstra Status feedback => resolved
2009-05-11 03:53 zesstra Fixed in Version => 3.3.719
2009-05-11 03:53 zesstra Resolution open => fixed
2009-05-11 03:53 zesstra Assigned To => zesstra
2009-05-11 03:55 zesstra Assigned To zesstra => Gnomi
2009-11-16 05:51 Gnomi Relationship added child of 0000705