12 Apr, 2015, MayaRK wrote in the 1st comment:
Votes: 0
We're having a segfault issue when trying to allocate memory using Diku's standard alloc_mem() function. This segfault happens very rarely and we're not sure what's causing it. Maybe someone has extensive experience with alloc_mem() and can give me an idea of what could be causing it. gdb output below:

Quote
#0 0x000000000059ffd1 in alloc_mem (sMem=4100) at memmgmt.c:1460
#1 0x00000000005a0ecf in add_buf (buffer=0x7f86dcf4f8e8,
string=0x7f86df8b2b47 "{WSyntax: toggle hardcore{x\n\r\n\r"…) at memmgmt.c:1894
#2 0x0000000000537ac4 in display_helpfile (ch=0x7f86dcf4d070,
argument=0x7fffd93cecf0 "hardcore", number=-1) at handler.c:2686
#3 0x0000000000456cdf in do_help (ch=0x7f86dcf4d070,
argument=0x7f86de280946 "hardcore") at act_info.c:4068
#4 0x000000000056b8d2 in interpret (ch=0x7f86dcf4d070,
argument=0x7f86de280946 "hardcore") at interp.c:1050
#5 0x00000000004c19d8 in substitute_alias (d=0x7f86de27fcf8,
argument=0x7f86de280941 "help hardcore") at alias.c:53
#6 0x00000000004e2f54 in game_loop (control=3) at comm.c:352
#7 0x00000000004e258b in main (argc=4, argv=0x7fffd93d50d8) at comm.c:197
(gdb) frame 0
#0 0x000000000059ffd1 in alloc_mem (sMem=4100) at memmgmt.c:1460
1460 rgFreeList[iList] = *((void **)rgFreeList[iList]);
(gdb) print iList
$4 = 11
(gdb) print *((void **)rgFreeList[iList])
Cannot access memory at address 0x74616854dd9d9288


Thanks in advance.
12 Apr, 2015, quixadhal wrote in the 2nd comment:
Votes: 0
Do you mean ROM's alloc_mem()? I don't think DikuMUD had such a thing…. at least mine doesn't.

ROM, OTOH, tried to not really free memory but put items on a seperate recycling list, which you are seeing in that stack trace as rgFreeList. This is a holdover from ancient times when the system malloc was actually noticeably slow on many systems.

Because of that, it's a pretty good guess that you've double-freed something, somewhere. An item got freed using ROM's code, and put on the recycle list, and then somewhere later it actually got freed for real. The result, an invalid entry on the recycle list. So, when you try to use ROM's code to recycle it (alloc_mem), it hands back an invalid entry, which of course crashes as soon as you try to access it.
12 Apr, 2015, MayaRK wrote in the 3rd comment:
Votes: 0
Thanks for the reply quixadhal, that was helpful. Yes, I mean ROM's alloc_mem(). You mentioned that ROM's way of not freeing memory but adding it to a recycling list is ancient. Is there any reason that I should continue using alloc_mem() and free_mem() vs. malloc() and free()? Thanks again.
12 Apr, 2015, quixadhal wrote in the 4th comment:
Votes: 0
No good reason, other than it already being there and it would take some work to unthread all the places that rely on it.

If you do though, you might want to look into gcmalloc(), which is a garbage collecting malloc. If you use that, free() becomes a no-op and you run garbage collection every so often in your main loop to free up unused items.

Even if you don't, using valgrind might help track down some of those kinds of issues. Good luck!
13 Apr, 2015, MayaRK wrote in the 5th comment:
Votes: 0
gcmalloc() sounds like an interesting option, I'll check it out. Thanks for all the info!
0.0/5