View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000007 | LDMud 3.3 | Other | public | 2003-07-29 16:35 | 2004-05-17 07:27 |
| Reporter | menaures | Assigned To | |||
| Priority | normal | Severity | crash | Reproducibility | random |
| Status | closed | Resolution | fixed | ||
| Summary | 0000007: UNItopia mudlib segfaults/hangs/crashes... | ||||
| Description | I just tried to run 3.3.467 using the UNItopia mudlib. Of course, UNItopia itself uses the 3.2.10 branch and therefore the lib is not 100% compatible to 3-3, so the experienced problems may not be that unusual. However... The driver produces random segfaults or hangs, eating the CPU away for no apparent reason. Everytime I try to locate the culprit LPC code, in the next try the crash happens somewhere else, in another object... (all during Preloading, though) There are no errormessages anywhere, just a few warnings. | ||||
| Steps To Reproduce | download mudlib.tar.gz run lib/doc/driver/setup_mudlib start driver [you may have to remove some simple syntax errors, like missing casts etc., since the lib is not 100% compatible to 3-3] restart driver... | ||||
| Additional Information | UNItopia has no plans yet to switch over to 3-3, I'm just playing around! So do not waste too much time for fixing those issues, if no other MUDs seem to have this kind of problem. Need more detailed information, like backtraces etc.? Contact me... | ||||
| Tags | No tags attached. | ||||
|
|
I just found a bug in the small block defragmentation which caused Evermore to crash. It is very possible that Unitopia fell victim to the same problem. Please try 3.3.468 and see if the problem persists. (Regarding the 'waste of time': even if the problem only showed up in Unitopia, it would only be a matter of time that some other mud is affected). |
|
|
3.3.468 is better. However, it still segfaults when loading apps/udl.c I can login now when removing this file. 3.3.468 also gave me a 'magic match failed' message one, but I couldn't reproduce it... Backtrace: Program terminated with signal 11, Segmentation fault. #0 0x0810aa3f in UNLINK_SMALL_FREE (block=0x832d194) at smalloc.c:785 prev = (word_t *) 0x832d3ec next = (word_t *) 0x117 bsize = 107308067 ix = 16 flag = 1 0000001 0x08108073 in mem_alloc (size=28) at smalloc.c:1246 pt = (word_t *) 0x832d194 split = (word_t *) 0x5001 wsize = 7 usize = 0 temp = (word_t *) 0x0 ix = 12 retry = 0 0000002 0x08109e24 in xalloc_traced (size=18) at xalloc.c:502 p = (word_t *) 0x39560 0000003 0x080bb89c in mstring_alloc_string (iSize=10) at mstrings.c:368 sdata = (string_data_t *) 0xbfffd61b string = (string_t *) 0xc 0000004 0x080bccf0 in mstring_add (left=0x832d81c, right=0x832d830) at mstrings.c:1239 lleft = 9 lright = 1 tmp = (string_t *) 0x80a2f48 0000005 0x08091f75 in eval_instruction (first_instruction=0x8354f76 "Ê`\n®b¤\233a3i.`\n®\n¯¸a[`\n®\n°¸a\003\016u", initial_sp=0x8156c00) at interpret.c:11024 left = (string_t *) 0x832d81c right = (string_t *) 0x832d830 len = 10 new_string = (string_t *) 0x11 type2 = 3 u2 = {str = 0x832d830, charp = 0x832d830 "", number = 137549872, ob = 0x832d830, vec = 0x832d830, strct = 0x832d830, map = 0x832d830, lambda = 0x832d830, mantissa = 137549872, cb = 0x832d830, generic = 0x832d830, lvalue = 0x832d830, protected_lvalue = 0x832d830, protected_char_lvalue = 0x832d830, protected_range_lvalue = 0x832d830, error_handler = 0x832d830} argp = (svalue_t *) 0x8156c78 pc = 0x8354ace "z\001\037\035\001\035\tÆ0%\n`\035\t\035\001<m\026" fp = (svalue_t *) 0x8156c60 sp = (svalue_t *) 0x8156cc0 num_arg = -1 instruction = 77 full_instr = 77 expected_stack = (svalue_t *) 0x0 ap = (svalue_t *) 0x8156c60 use_ap = 0 0000006 0x0809b875 in apply_low (fun=0x8337d3c, ob=0x8335384, num_arg=1, b_ign_prot=0, allowRefs=0) at interpret.c:16198 flags = 9452 funstart = 0x8354f74 "" fx = 37 progp = (program_t *) 0x8352a28 save_csp = (struct control_stack *) 0x815e9f0 ix = 3587 0000007 0x0809ba44 in int_apply (fun=0x8337d3c, ob=0x8335384, num_arg=1, b_ign_prot=0, b_use_default=1) at interpret.c:16276 No locals. 0000008 0x0809be70 in sapply_int (fun=0x8337d3c, ob=0x8335384, num_arg=1, b_find_static=0, b_use_default=1) at interpret.c:16437 expected_sp = (svalue_t *) 0x8156c00 0000009 0x080bee35 in reset_object (ob=0x8335384, arg=5) at object.c:865 No locals. 0000010 0x080f379a in load_object (lname=0x8187a20 "apps/udl", create_super=0, depth=0, chain=0x0) at simulate.c:1948 svp = (svalue_t *) 0x832b518 j = -1 save_current = (object_t *) 0x820dbd0 fd = 5 ob = (object_t *) 0x8335384 save_command_giver = (object_t *) 0x0 i = 7 c_st = {st_dev = 5634, __pad1 = 0, st_ino = 968907, st_mode = 33188, st_nlink = 1, st_uid = 1000, st_gid = 1000, st_rdev = 0, __pad2 = 0, st_size = 54240, st_blksize = 4096, st_blocks = 120, st_atim = {tv_sec = 1059522069, tv_nsec = 0}, st_mtim = {tv_sec = 1059522488, tv_nsec = 0}, st_ctim = {tv_sec = 1059522488, tv_nsec = 0}, __unused4 = 0, __unused5 = 0} name_length = 8 name = 0xbfffdb80 "/apps/udl" fname = 0xbfffdb70 "apps/udl.c" prog = (program_t *) 0x8352a28 nlink = {prev = 0x0, name = 0xbfffdb81 "apps/udl"} 0000011 0x080f3f98 in lookfor_object (str=0x820a2c8, bLoad=1) at simulate.c:2205 ob = (object_t *) 0x0 pName = 0x8187a20 "apps/udl" 0000012 0x080f6e17 in f_load_object (sp=0x8156c00) at simulate.c:4150 ob = (object_t *) 0x2 0000013 0x08088f67 in eval_instruction (first_instruction=0x83460a3 "\035", initial_sp=0x8156bf8) at interpret.c:7524 code = 34 pc = 0x83460a7 "³az\005(\002\vz\002(\035\005i\020\nÏ\035\005)\nÐ)\035" fp = (svalue_t *) 0x8156bc8 sp = (svalue_t *) 0x8156c00 num_arg = -1 instruction = 258 full_instr = 258 expected_stack = (svalue_t *) 0x0 ap = (svalue_t *) 0x8156bc8 use_ap = 0 #14 0x080f0c53 in catch_instruction (flags=0, offset=5, i_sp=0x81c9444, i_pc=0x83460a3 "\035", i_fp=0x8156bc8, i_context=0x0) at simulate.c:418 rc = 135621640 old_out_of_memory = 0 new_pc = 0x83460a8 "az\005(\002\vz\002(\035\005i\020\nÏ\035\005)\nÐ)\035" #15 0x0808b5a1 in eval_instruction (first_instruction=0x8346046 "_\001\005\035", initial_sp=0x8156bf0) at interpret.c:8839 offset = 5 flags = 0 pc = 0x83460a3 "\035" fp = (svalue_t *) 0x8156bc8 sp = (svalue_t *) 0x8156bf8 num_arg = -1 instruction = 30 full_instr = 30 expected_stack = (svalue_t *) 0x0 ap = (svalue_t *) 0x8156c00 use_ap = 0 #16 0x0809b46e in apply_low (fun=0x81cd464, ob=0x820dbd0, num_arg=1, b_ign_prot=1, allowRefs=0) at interpret.c:16086 funstart = 0x8346044 "\001\005_\001\005\035" progp = (program_t *) 0x8343924 save_csp = (struct control_stack *) 0x815e968 ix = 1448 #17 0x0809ba44 in int_apply (fun=0x81cd464, ob=0x820dbd0, num_arg=1, b_ign_prot=1, b_use_default=0) at interpret.c:16276 No locals. #18 0x0809be70 in sapply_int (fun=0x81cd464, ob=0x820dbd0, num_arg=1, b_find_static=1, b_use_default=0) at interpret.c:16437 expected_sp = (svalue_t *) 0x8156bc0 #19 0x0809c67d in apply_master_ob (fun=0x81cd464, num_arg=1, external=0) at interpret.c:16731 eval_cost_reserve = 512 reserve_used = 0 error_recovery_info = {rt = {last = 0x8139060, type = 2}, flags = 16843009, con = {text = {{__jmpbuf = {4, 135497856, 136090976, -1073748344, -1073748608, 134858191}, __mask_was_saved = 0, __saved_mask = {__val = {16843009, 16843009, 16843009, 16843009, 16843009, 16843009, 16843009, 16843009, 16843009, 16843009, 16843008, 16843009, 16843009, 16843009, 16843009, 16843009, 65793, 16843009, 16843009, 16843009, 16843009, 16843009, 16843009, 16843009, 16843009, 16842753, 16843009, 16843009, 65793, 4294967295, 4294967295, 136369564}}}}}} save_sp = (svalue_t *) 0x8156bc8 save_csp = (struct control_stack *) 0x815e924 result = (svalue_t *) 0x813393c #20 0x08054eff in preload_objects (eflag=0) at backend.c:1210 prefiles = (vector_t *) 0x82273c4 ret = (svalue_t *) 0x813393c ix0 = 2 num_prefiles = 64 ix = 2 #21 0x080b0aec in main (argc=1, argv=0xbffff864) at main.c:547 i = 5 p = 0xbffff7fc "\005" set = {__val = {8192, 0 <repeats 31 times>}} rc = 0 #22 0x400d8747 in __libc_start_main () from /lib/libc.so.6 No symbol table info available. |
|
|
Uh, aggressive auto-replace thingy... can I turn this of somehow? Those buglinks in the backtrace weren't supposed to be there... |
|
|
When splitting a larger small block into two small ones to satisfy an allocation, the allocator clobbered the PREV_BLOCK flag in the first of the two blocks. Later, when this block had been freed again, the defragmentation couldn't fulfill the invariant that after merging a block with its neighbours, it really did have only allocated blocks as remaining neighbours, and subsequently clobbered its lists. Example: Four free blocks: 0x100 (16 words) 0x140 (4 words) 0x150 (16 words, clobbered PREV_BLOCK flag) 0x190 (4 words) and the free list for 16-word blocks lists 0x150 before 0x100. The defragmentation will now find 0x150 first and merge it with 0x190. Since the PREV_BLOCK flag is wrong, it won't find 0x140 and thus put the new 0x150 block into 'defragged' list. Next, the defragmentation will find 0x100 and merge it with 0x140 AND 0x150 - since the invariant is supposed to guarantee that 0x150 has not been seen yet, the defragmenter doesn't check the 'defragged' list. In the end, the 'defragged' list contains two blocks - 0x100 (40 words) and 0x150 (20 words) - of which only 0x100 is valid, yet both are returned to the allocator as available free blocks. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2003-07-29 16:35 | menaures | New Issue | |
| 2003-07-29 16:43 |
|
Note Added: 0000015 | |
| 2003-07-29 16:44 |
|
Assigned To | => lars |
| 2003-07-29 16:44 |
|
Status | new => acknowledged |
| 2003-07-29 17:53 | menaures | Note Added: 0000016 | |
| 2003-07-29 17:57 | menaures | Note Added: 0000017 | |
| 2003-07-31 23:50 |
|
Status | acknowledged => resolved |
| 2003-07-31 23:50 |
|
Resolution | open => fixed |
| 2003-07-31 23:50 |
|
Note Added: 0000018 | |
| 2004-05-17 07:27 |
|
Status | resolved => closed |
