View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000622 | LDMud 3.3 | Runtime | public | 2009-04-08 17:10 | 2009-05-11 01:55 |
| Reporter | garapol | Assigned To | Gnomi | ||
| Priority | normal | Severity | crash | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.3.717 | ||||
| Fixed in Version | 3.3.719 | ||||
| Summary | 0000622: GeoLiteCity as big switch-blocks crashes on high usage | ||||
| Description | I 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 Information | The 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 GeoLiteCityConverter.java 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. | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
|
|
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. |
|
|
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')? |
|
|
There is btw a mistake in the zlpc command. The arguments to query_town() are strings (results from explode()), but query_town() expects ints. |
|
|
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). |
|
|
I managed to run the generator after downloading the csv database from http://www.maxmind.com/app/geolitecity. 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 127.0.0.1, so unsurprisingly it didn't do much.) |
|
|
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/zmarker.inc)' (' obj/zepter#955457') line 359 ' start_lpc' in 'i/zepter/zepter.c (/i/zepter/zmarker.inc)' (' 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 |
|
|
Can we assume, that was fixed by Gnomis change? Or is there any new information? |
|
|
Avalon uses another system, but I am sure Gnomi found the bug. But I did not try. |
|
|
Apparently fixed by Gnomi in r2540. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2009-04-08 17:10 | garapol | New Issue | |
| 2009-04-08 17:10 | garapol | File Added: avalon_absturz.zip | |
| 2009-04-08 17:12 | garapol | Note Added: 0001014 | |
| 2009-04-09 01:06 | Gnomi | Note Added: 0001015 | |
| 2009-04-09 01:10 | Gnomi | Note Added: 0001016 | |
| 2009-04-09 08:17 | zesstra | Note Added: 0001017 | |
| 2009-04-09 09:03 | fufu | Note Added: 0001018 | |
| 2009-04-12 15:29 | garapol | Note Added: 0001021 | |
| 2009-05-10 15:30 | zesstra | Note Added: 0001095 | |
| 2009-05-10 15:30 | zesstra | Status | new => feedback |
| 2009-05-11 00:14 | garapol | Note Added: 0001100 | |
| 2009-05-11 01:53 | zesstra | Note Added: 0001101 | |
| 2009-05-11 01:53 | zesstra | Status | feedback => resolved |
| 2009-05-11 01:53 | zesstra | Fixed in Version | => 3.3.719 |
| 2009-05-11 01:53 | zesstra | Resolution | open => fixed |
| 2009-05-11 01:53 | zesstra | Assigned To | => zesstra |
| 2009-05-11 01:55 | zesstra | Assigned To | zesstra => Gnomi |
| 2009-11-16 04:51 | Gnomi | Relationship added | child of 0000705 |
