View Issue Details

IDProjectCategoryView StatusLast Update
0000893LDMud 3.2Compilation, Installationpublic2022-10-06 18:07
Reporterbuzzom Assigned ToGnomi  
PrioritynormalSeveritycrashReproducibilityalways
Status closedResolutionfixed 
Product Version3.2.17 
Summary0000893: Driver stops because of smalloc.c:3458
DescriptionUnfortunately, the driver does not start after the successful compilation. It stops here:

2021.05.31 11:20:29 LDMud 3.2.17 (Build $Revision$) (development)
2021.05.31 11:20:29 Random seed: 0x60b4aa5d

I tested with GDB what could be the cause. The following result was displayed to me:

0x0000563040f35f1e in calloc (nelem=<optimized out>, sizel=1) at smalloc.c:3458
3458 p = malloc(nelem * sizel);

(gdb) list
3453 {
3454 char *p;
3455
3456 if (nelem == 0 || sizel == 0)
3457 return NULL;
3458 p = malloc(nelem * sizel);
3459 if (p == NULL)
3460 return NULL;
3461 memset(p, '\0', nelem * sizel);
3462 return p;
(gdb)

What could I do to be able to start the driver and MudLib after all?

Thank you very much
Eric
Additional InformationMy system:

OS: Ubuntu 18.04.5 LTS x86_64
Kernel: 4.15.0
CPU: Intel Xeon E5-2680 v2 (4) @ 1.999GHz
Memory: 87MiB / 8192MiB
TagsNo tags attached.

Relationships

duplicate of 0000862 resolvedzesstra LDMud 3.5 Segmentation fault during startup 

Activities

Gnomi

2021-05-31 10:04

manager   ~0002630

Please try to compile the driver with -fno-optimize-strlen or -fno-builtin-malloc

buzzom

2021-05-31 11:59

reporter   ~0002631

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

buzzom

2021-05-31 14:16

reporter   ~0002632

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)

Gnomi

2021-05-31 17:48

manager   ~0002633

As you saw yourself, line 204 in main.c doesn't contain any code. What is the exact output of gdb?

zesstra

2021-05-31 18:10

administrator   ~0002634

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.

buzzom

2021-05-31 18:11

reporter   ~0002635

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

buzzom

2021-05-31 18:28

reporter   ~0002636

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:

Gnomi

2021-05-31 18:35

manager   ~0002637

What is the output of the 'bt' command in gdb?

buzzom

2021-05-31 18:36

reporter   ~0002638

"No stack."

Gnomi

2021-05-31 18:41

manager   ~0002639

Please show all of your input and the corresponding output of your analysis of the segmentation fault in gdb.

buzzom

2021-05-31 18:49

reporter   ~0002640

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.

Gnomi

2021-05-31 18:54

manager   ~0002641

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.

buzzom

2021-05-31 18:58

reporter   ~0002642

Do you mean by 'core' file: /mudlib/secure/master.c ?

Gnomi

2021-05-31 19:01

manager   ~0002643

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).

zesstra

2021-05-31 19:02

administrator   ~0002644

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.

buzzom

2021-05-31 19:27

reporter   ~0002645

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. :-)

Gnomi

2021-05-31 19:43

manager   ~0002646

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.

buzzom

2021-06-01 10:01

reporter   ~0002647

As far as I can sees, it is all set like you both said:

buzzom

2021-06-01 10:04

reporter   ~0002648

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)

Gnomi

2021-06-01 14:15

manager   ~0002649

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.

Gnomi

2021-06-01 14:19

manager   ~0002650

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.

Gnomi

2021-06-01 14:24

manager   ~0002651

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)

buzzom

2021-06-01 14:42

reporter   ~0002652

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.

buzzom

2021-06-01 14:44

reporter   ~0002653

Sorry, I meant up to 3.6.4

buzzom

2021-06-02 07:36

reporter   ~0002654

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?

Gnomi

2022-10-06 18:07

manager   ~0002686

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.

Issue History

Date Modified Username Field Change
2021-05-31 10:00 buzzom New Issue
2021-05-31 10:04 Gnomi Note Added: 0002630
2021-05-31 11:59 buzzom Note Added: 0002631
2021-05-31 11:59 buzzom File Added: Bildschirmfoto 2021-05-31 um 13.56.32.png
2021-05-31 14:16 buzzom Note Added: 0002632
2021-05-31 17:48 Gnomi Note Added: 0002633
2021-05-31 18:10 zesstra Note Added: 0002634
2021-05-31 18:11 buzzom Note Added: 0002635
2021-05-31 18:28 buzzom Note Added: 0002636
2021-05-31 18:28 buzzom File Added: Bildschirmfoto 2021-05-31 um 20.25.55.png
2021-05-31 18:35 Gnomi Note Added: 0002637
2021-05-31 18:36 buzzom Note Added: 0002638
2021-05-31 18:41 Gnomi Note Added: 0002639
2021-05-31 18:49 buzzom Note Added: 0002640
2021-05-31 18:49 buzzom File Added: Bildschirmfoto 2021-05-31 um 20.45.15.png
2021-05-31 18:54 Gnomi Note Added: 0002641
2021-05-31 18:58 buzzom Note Added: 0002642
2021-05-31 19:01 Gnomi Note Added: 0002643
2021-05-31 19:02 zesstra Note Added: 0002644
2021-05-31 19:27 buzzom Note Added: 0002645
2021-05-31 19:43 Gnomi Note Added: 0002646
2021-05-31 19:44 Gnomi Relationship added duplicate of 0000862
2021-06-01 10:01 buzzom Note Added: 0002647
2021-06-01 10:01 buzzom File Added: Bildschirmfoto 2021-06-01 um 11.58.50.png
2021-06-01 10:01 buzzom File Added: Bildschirmfoto 2021-06-01 um 11.58.10.png
2021-06-01 10:01 buzzom File Added: Bildschirmfoto 2021-06-01 um 11.57.39.png
2021-06-01 10:04 buzzom Note Added: 0002648
2021-06-01 14:15 Gnomi Note Added: 0002649
2021-06-01 14:19 Gnomi Note Added: 0002650
2021-06-01 14:24 Gnomi Note Added: 0002651
2021-06-01 14:42 buzzom Note Added: 0002652
2021-06-01 14:44 buzzom Note Added: 0002653
2021-06-02 07:36 buzzom Note Added: 0002654
2022-10-06 18:07 Gnomi Assigned To => Gnomi
2022-10-06 18:07 Gnomi Status new => closed
2022-10-06 18:07 Gnomi Resolution open => fixed
2022-10-06 18:07 Gnomi Note Added: 0002686