|
|
Please try to compile the driver with -fno-optimize-strlen or -fno-builtin-malloc |
|
|
Thank you it helped a lot. Unfortunately the driver stops with a Memory access failure and I do not know why. I would be very thankfull for any help or advice Eric Bildschirmfoto 2021-05-31 um 13.56.32.png (156,803 bytes) |
|
|
GDB says to this segmentation fault: (in /src/main.c line 204) Reading symbols from ./ldmud...fertig. (gdb) list 204 typedef struct FData { 205 struct FData * next; 206 char txt[1]; /* The value, allocated to size */ 207 } FData; 208 209 static FData * f_head = NULL; 210 static FData * f_tail = NULL; 211 212 /*-------------------------------------------------------------------------*/ 213 int (gdb) |
|
|
As you saw yourself, line 204 in main.c doesn't contain any code. What is the exact output of gdb? |
|
|
I would also suggest to configure the driver with --with-malloc=sysmalloc and check if that helps. Also try to configure with --with-optimize=no or ensure otherwise (e.g. by editing the Makefile after configure) that the driver is compiled with -O0 or no -O argument at all. This might remove the crash, but in any case it will improve gdb's information. |
|
|
Hello Gnomi, that was the output, when I startet ./ldmud in the bin directory via "gdb ./ldmud" When I searched for the code for "typedef struct FData" with Midnight Commander, he show me, main.c from the /ldmud/src/ directory of the driver Software. But you are right, it starts on line: 271 in main.c (my mistake) Thank you very much Eric |
|
|
Thank you Zesstra also for your help. I tried (--with-malloc=sysmalloc --with-optimize=no) what you said, but unfortunately it makes no difference. Also GDB does not give me more Information as already mentioned above. Here a screenshot from the code GDB declares: Bildschirmfoto 2021-05-31 um 20.25.55.png (74,122 bytes) |
|
|
What is the output of the 'bt' command in gdb? |
|
|
"No stack." |
|
|
Please show all of your input and the corresponding output of your analysis of the segmentation fault in gdb. |
|
|
I hope, I have understood you correctly. Please excure me, if I act kind of noobish in this matter, as my skills here are only on novice level. :-) But I'll try my best and I am very thankfull for your help. Bildschirmfoto 2021-05-31 um 20.45.15.png (84,956 bytes) |
|
|
Okay, thanks. You were starting gdb with the binary, but not analyzing the segmentation fault. To analyze the segmentation fault we need a 'core' file. That should lie in the mudlib directory. If there is none, then you might need to activate core file generation with 'ulimit -c unlimited' before starting your mud. If you have a core file, you'll need to start gdb with: 'gdb ./ldmud path-to-the-core-file' And then you can execute 'bt' to show the backtrace. |
|
|
Do you mean by 'core' file: /mudlib/secure/master.c ? |
|
|
I mean a file named 'core', this will usually be generated by the Linux kernel when a segmentation fault happens (unless prevented by the current limits). |
|
|
No. "core dumps" are a memory state your operating system creates, when a process crashes to enable debugging that crash. How you get your OS to do that depends on the OS. Alternatively, you could - in your gdb session - start the driver with the command "run". When it crashes, you will get a prompt and can issue the "bt" command (try "bt full"). BTW: Please also make sure, that when you change something with configure, you clean old binaries first ("make clean"). Out of curiosity: From the output I assume that you use a variant of the MG-mudlib. But that was never working with LDMud 3.2.x: could you tell us which mudlib that is you want to start/work with. |
|
|
I activated 'ulimit -c unlimited' and run the program but nor core file could be found within /home/mud , where all the mud related files are. Then I tried to run the driver in my gdb session with 'run' with the following output: Program received signal SIGSEGV, Segmentation fault. __GI___rewinddir (dirp=0x555555e45698) at ../sysdeps/posix/rewinddir.c:34 34 ../sysdeps/posix/rewinddir.c: Datei oder Verzeichnis nicht gefunden. The output of 'bt full' is: (gdb) bt full #0 __GI___rewinddir (dirp=0x555555e45698) at ../sysdeps/posix/rewinddir.c:34 No locals. 0000001 0x000055555560afa7 in e_get_dir (path=0x555555b35880 "save/*", mask=1) at simulate.c:5522 ec = {head = {type = 20, x = {string_type = 0, exponent = 0, closure_type = 0, quotes = 0, num_arg = 0, extern_args = 0, generic = 0}, u = { string = 0x55555560a6dc <get_dir_error_handler> "UH\211\345H\203\354 H\211}\350H\213E\350H\211E\370H\213\005q*1", number = 93824992978652, ob = 0x55555560a6dc <get_dir_error_handler>, vec = 0x55555560a6dc <get_dir_error_handler>, map = 0x55555560a6dc <get_dir_error_handler>, lambda = 0x55555560a6dc <get_dir_error_handler>, mantissa = 93824992978652, cb = 0x55555560a6dc <get_dir_error_handler>, lvalue = 0x55555560a6dc <get_dir_error_handler>, protected_lvalue = 0x55555560a6dc <get_dir_error_handler>, protected_char_lvalue = 0x55555560a6dc <get_dir_error_handler>, protected_range_lvalue = 0x55555560a6dc <get_dir_error_handler>, error_handler = 0x55555560a6dc <get_dir_error_handler>}}, dirp = 0x555555e45698, v = 0x555555d408e8} v = 0x555555d408e8 w = 0x555555accf88 i = 21845 j = -1441093865 count = 30 dirp = 0x555555e45698 namelen = 1 do_match = 1 de = 0x0 st = {st_dev = 140737488328736, st_ino = 93824992992480, st_nlink = 140737488328784, st_mode = 1440263608, st_uid = 21845, st_gid = 1437388624, __pad0 = 21845, st_rdev = 93825000844672, st_size = 140737488328768, st_blksize = 93824992514910, st_blocks = 3, st_atim = {tv_sec = 93825000844728, tv_nsec = 140737488328848}, st_mtim = {tv_sec = 93824992520989, tv_nsec = 93824998455291}, st_ctim = {tv_sec = 93824995389712, tv_nsec = 93824995389632}, __glibc_reserved = {93824995389712, 140737488328848, 1431935059}} temppath = 0x7fffffff9730 "save" templen = 4 in_top_dir = 0 p = 0x7fffffff9734 "" regexpr = 0x7fffffff9710 "*" nqueries = 1 0000002 0x00005555555b72fe in eval_instruction (first_instruction=0x555555b437a3 "R\002\003t\333\033", initial_sp=0x555555857100 <value_stack_array+288>) at interpret.c:17345 v = 0xffffe816ffffa500 pc = 0x555555b437fd "\026\033\004\r\020\002;\a*\244\a-'c\003&\033\002\a.\a/\016\003\246c\002&\033\002\a0\a1\016\003\246c\002&\a2\033\002\a3\a4\016\003\246'\a5'c\002&\033\003\016\241\033\002\316\026\027\360,\264UUU" fp = 0x5555558570c0 <value_stack_array+224> sp = 0x555555857120 <value_stack_array+320> num_arg = -1 instruction = 161 expected_stack = 0x0 0000003 0x00005555555adef4 in eval_instruction (first_instruction=0x555555d6928b "R", initial_sp=0x5555558570b0 <value_stack_array+208>) at interpret.c:12327 prog = 0x555555b43118 new_sp = 0x555555857100 <value_stack_array+288> code = 7 funstart = 0x555555b437a1 "\002\003R\002\003t\333\033" ob = 0x555555ac3188 entry = 0x55555591d460 <simul_efun_table+224> pc = 0x555555d692a8 "\a\033\aFq\002" fp = 0x555555856ff0 <value_stack_array+16> sp = 0x5555558570c0 <value_stack_array+224> num_arg = 1 instruction = 112 expected_stack = 0x0 0000004 0x00005555555be83b in apply_low (fun=0x555555d8bc20 "create_ab_list", ob=0x555555ceb0b8, num_arg=15, b_ign_prot=0) at interpret.c:21684 flags = 1489 funstart = 0x555555d69289 "" fx = 10 shared_name = 0x555555d8bc20 "create_ab_list" progp = 0x555555d68c10 save_csp = 0x555555866ae0 <control_stack_array+224> ix = 296 0000005 0x00005555555beafb in sapply_int (fun=0x555555d8bc20 "create_ab_list", ob=0x555555ceb0b8, num_arg=15, b_find_static=0) at interpret.c:21796 expected_sp = 0x555555856fe0 <value_stack_array> 0000006 0x0000555555607cc1 in execute_callback (cb=0x555555d8b240, nargs=0, keep=0, toplevel=1) at simulate.c:3695 ob = 0x555555ceb0b8 num_arg = 15 0000007 0x0000555555569ef5 in call_out () at call_out.c:431 ob = 0x555555ceb0b8 cop = 0x555555d8b238 user = 0x555555b25fd8 last_time = 1622488541 current_call_out = 0x555555d8b238 called_object = 0x555555ceb0b8 ---Type <return> to continue, or q <return> to quit--- error_recovery_info = {rt = {last = 0x5555558d7280 <toplevel_context>, type = 1}, flags = 0, con = {text = {{__jmpbuf = {8461471387573250095, 1592344796912864868, 93824992261632, 140737488348544, 0, 0, 1592344796870921828, 4849374548140805732}, __mask_was_saved = 0, __saved_mask = {__val = {140737345734528, 140737488341456, 54100216659024, 13549229119100283392, 93824999844432, 8461471387573250095, 140737488341488, 93824992261632, 140737488348544, 0, 0, 140737342505014, 93824992261632, 13549229119100283392, 140737488341488, 93824992924846}}}}}} 0000008 0x0000555555566d5a in backend () at backend.c:644 buff = "\000\000\000\000\000\000\000\000\207\337`UUU\000\000\000\000\000\000\000\000\000\000\360\344\253UUU\000\000\000\000\000\000\002\000\000\000\220_\222U\251\071\000\000\360\344\253UUU\000\000\000\000\000\000\000\000\000\000\270\344\253UUU\000\000\000\000\000\000\000\000\000\000\220\313\377\377\377\177\000\000\070\346`UUU\000\000\060\314\377\377\377\177\000\000\360\344\253UUU\000\000\270\344\253UUU\000\000\360\344\253UUU\000\000\300\204\253UUU\000\000hl\253UUU\000\000\340\313\377\377\377\177\000\000\360\351\250UUU\000\000<'\364\003\000\000\001\000P2\254UUU\000\000P2\254UUU\000\000\260$\254UUU\000\000\001\002\000\000\000\000\000\000"... 0000009 0x00005555555ce97b in main (argc=2, argv=0x7fffffffe588) at main.c:517 i = 5 p = 0x7fffffffd35c "\005" set = {__val = {8192, 0 <repeats 15 times>}} I always delete the compiled driver and the makefile before starting an new configure process and new compiling. But thank you for the 'make clean' advice, I'll do that now. Your curiosity is understandable :-) Some years ago, some friends of mine, who played SilberLand, wanted to create our own MUD, which we did. We called it NordLand. It run lastely successfully on LDMud 3.2.13 on another server which is no more. I only could save the MudLib from that days. Basicly it is a SilberLand MudLib which we have adapted to our needs as far at is was necessary. But in essence and at its core it is a SilberLand MudLib. We would like to bring the NordLand back to life, as there was a lot of work in it and some people are very interested in it again. And of course it's a lot of fun. :-) |
|
|
Okay, you're crashing in rewinddir. This points to a conflict with the memory allocation routines. Did you really compile with --with-malloc=sysmalloc? Please verify this. Check that in your config.h of your driver sources there is a line #define MALLOC_sysmalloc and that your binary has a newer date than this config.h. |
|
|
As far as I can sees, it is all set like you both said: Bildschirmfoto 2021-06-01 um 11.58.50.png (96,188 bytes) Bildschirmfoto 2021-06-01 um 11.58.10.png (170,481 bytes) Bildschirmfoto 2021-06-01 um 11.57.39.png (100,698 bytes) |
|
|
But now, with above settings gbd givs another output : Program received signal SIGSEGV, Segmentation fault. 0x000055555559effd in eval_instruction (first_instruction=0x555555cca59b "R", initial_sp=0x55555584cf50 <value_stack_array+208>) at interpret.c:6669 6669 instruction = LOAD_CODE(pc); (gdb) bt full #0 0x000055555559effd in eval_instruction (first_instruction=0x555555cca59b "R", initial_sp=0x55555584cf50 <value_stack_array+208>) at interpret.c:6669 pc = 0xaaaa55cca792 <error: Cannot access memory at address 0xaaaa55cca792> fp = 0x55555584ce90 <value_stack_array+16> sp = 0x55555584cf50 <value_stack_array+208> num_arg = -1 instruction = 83 expected_stack = 0x0 0000001 0x00005555555bb76a in apply_low (fun=0x555555c00fc0 "create_ab_list", ob=0x555555bcb650, num_arg=15, b_ign_prot=0) at interpret.c:21684 flags = 1489 funstart = 0x555555cca599 "" fx = 10 shared_name = 0x555555c00fc0 "create_ab_list" progp = 0x555555cc9f20 save_csp = 0x55555585c980 <control_stack_array+224> ix = 835 0000002 0x00005555555bba2a in sapply_int (fun=0x555555c00fc0 "create_ab_list", ob=0x555555bcb650, num_arg=15, b_find_static=0) at interpret.c:21796 expected_sp = 0x55555584ce80 <value_stack_array> 0000003 0x0000555555605195 in execute_callback (cb=0x555555cba058, nargs=0, keep=0, toplevel=1) at simulate.c:3695 ob = 0x555555bcb650 num_arg = 15 0000004 0x0000555555569b46 in call_out () at call_out.c:431 ob = 0x555555bcb650 cop = 0x555555cba050 user = 0x555555a1ee70 last_time = 1622541785 current_call_out = 0x555555cba050 called_object = 0x555555bcb650 error_recovery_info = {rt = {last = 0x5555558cd120 <toplevel_context>, type = 1}, flags = 0, con = {text = {{__jmpbuf = {8461471387573250095, -5908961667403163889, 93824992261440, 140737488348512, 0, 0, -5908961667428329713, -528482492544919793}, __mask_was_saved = 0, __saved_mask = {__val = {140737345734528, 140737488341424, 58485378294864, 9873060355983394816, 93824997967728, 8461471387573250095, 140737488341456, 93824992261440, 140737488348512, 0, 0, 140737342505014, 93824992261440, 9873060355983394816, 140737488341456, 93824992914051}}}}}} 0000005 0x00005555555669a8 in backend () at backend.c:644 buff = '\000' <repeats 24 times>, "\240s\224UUU\000\000\000\000\000\000\002\000\000\000 )\231U\251\071\000\000\240s\224UUU\000\000\000\000\000\000\000\000\000\000\300s\224UUU\000\000\000\000\000\000\000\000\000\000p\313\377\377\377\177\000\000-\267`Ud\000\000\000]=cUUU\000\000\020\000\000\000\000\000\000\000@\265UUUU\000\000`\345\377\377\377\177\000\000\260~\224UUU\000\000p\205\224UUU\000\000\300\313\377\377\377\177\000\000\254\260`UUU\000\000\340\271\376\367\377\177\000\000]=cUUU\000\000\001\000\000\000\000\000\000\000`\207\177\367\023\035\000\000p\205\224UUU\000\000\000\000\000\000\000\000\000\000"... 0000006 0x00005555555cb6fa in main (argc=1, argv=0x7fffffffe568) at main.c:517 i = 5 p = 0x7fffffffd33c "\005" set = {__val = {8192, 0 <repeats 15 times>}} (gdb) |
|
|
Nothing comes to mind which could explain this. This crash happens in a call_out to a function "create_ab_list". It seems that the program counter is not correct, so there might be an issue with a function call/return. You could try to deactivate certain parts of this function (commenting out) to see which LPC code causes this. |
|
|
Generally I would advise switching to a newer version. LDMud 3.2.17 is now over 11 years old and will not receive any updates. |
|
|
Oh, this could easily be a 64bit issue. The LDMud 3.2 series is not ready for 64bit machines, try to compile it as a 32bit application (CFLAGS and LDFlags with -m32) |
|
|
Thank you Gnomi. Yes, the 32 Bit also came into my mind. I will try that and report, if any issure might occur. I would love to upgrade to 3.2.17, but that would involve a lot of work on the MudLib. First I wanted to see whether I can reactivate the MudLib with a more compatible driver and then work my way up to 3.2.17, bit by bit with the conversion of the efuns. |
|
|
Sorry, I meant up to 3.6.4 |
|
|
After compiling with CFLAGS="-m32" & LDFLAGS="-m32" in the Makefile & with_malloc=sysmalloc in ./configure, the MudLib is running. Still some bug within the MudLib, but that is another task. Thank you so much for helping. Can I fund the LDMud Project somehow? Patreon? |
|
|
We don't have Patreon or any other donation possibility. If you want to donate something, please donate to some charity that really could use money to do some good. |
- Anonymous
