tinymush / historical-tinymush Goto Github PK

Ran ./configure ; openssl version at the end of the output:

## -------------------- ##
## Checks for libraries ##
## -------------------- ##

checking for library containing crypt... -lcrypt
checking for library containing SSL_library_init... no
configure: error: in `/home/arenlor/TinyMUSH-master':
configure: error: could not find library openssl
See `config.log' for more details
OpenSSL 1.1.0h  27 Mar 2018

Not sure how to fix this myself.

So, I built TM3.2 on Ubuntu 14.04.5 (x86_64), it compiled fine. The game had been running for maybe two days with no issues whatsoever but then I did a @restart, and when the server finished starting up, I discovered that a couple of functions were no longer working. I checked the object they were defined on and discovered that while the attribute name still showed up on an examine, the text with the code for the function was gone. Not sure what had happened, I restored from backup and continued working for several more days before I did another @restart, and this time when the server finished rebooting, the name for #0 had disappeared.

Any idea what might be causing this? I would really like to continue using TM for my project but I am afraid to do anything now for fear of what I might lose next.

Hi!

I pulled 3.2 from git (18790b9) and built it on openSUSE Linux 13.2 (x86_64). I imported my 3.0 db. MUSH comes up and serves connections etc., but I'm seeing a lot of crashes of the form,

*** Error in `./bin/netmush': double free or corruption (fasttop): 0x0000000000e
46170 ***
#0 0x00007f170d1c6187 in raise () from /lib64/libc.so.6
#1 0x00007f170d1c7538 in abort () from /lib64/libc.so.6
#2 0x00007f170d203844 in __libc_message () from /lib64/libc.so.6
#3 0x00007f170d2090ae in malloc_printerr () from /lib64/libc.so.6
#4 0x00007f170d209db6 in _int_free () from /lib64/libc.so.6
#5 0x0000000000520bc4 in objfree (o=0xdff770) at udb_obj.c:213
#6 0x00000000005213cb in get_free_objpipe (obj=1100) at udb_obj.c:420
#7 0x0000000000521573 in pipe_get_attrib (anum=64, obj=1100) at udb_obj.c:461
#8 0x000000000051ebf5 in cache_get (key=..., type=1) at udb_ocache.c:501
#9 0x00000000004382d2 in atr_get_raw (thing=1100, atr=64) at db.c:2007
#10 0x00000000004384c6 in atr_pget_str (s=0xe2c5d0 "", thing=1100, atr=64,

owner=0x7fff109521b0, flags=0x7fff109521bc, alen=0x7fff109521b8)
at db.c:2069

#11 0x000000000043884b in atr_pget (thing=1100, atr=64, owner=0x7fff109521b0,

flags=0x7fff109521bc, alen=0x7fff109521b8) at db.c:2112

#12 0x000000000041a0a6 in process_command (player=72, cause=72, interactive=1,

command=0xe515f8 "ooc meow", args=0x0, nargs=0) at command.c:1084

#13 0x00000000004cf249 in do_command (d=0xdee8e0, command=0xe515f8 "ooc meow",

first=1) at netcommon.c:1789

#14 0x00000000004cf7d9 in process_commands () at netcommon.c:1920
#15 0x000000000051b520 in shovechars (port=7000) at bsd.c:334
#16 0x00000000004a8666 in main (argc=17, argv=0x7fff10952758) at game.c:2297

Always in get_free_objpipe, as far as I've seen.
Same behavior when testing in a VM (on different underlying hardware, and with a Fedora guest; still x86_64 though).

Have imported via flat-file from tm3.0; later tried Reconstruct, @dbck, flatfile from 3.2 -> 3.2, pretty much anything I could think of. Problem persists.

"A lot" in this context: "at least one crash a day now that not much is happening; easily every ten minutes during heavy grid building."

Please advise:

• is there anything else short of a complete @decompile/replay cycle I can do to give my db some love? But then again, should anything that completes as a valid flat import be able to crash the cache?
• Am I using the recommended version of the server? I had a cursory look at 3.3, but got a little scared when I saw that scripts and command line syntax had changed -- plus, of course, the designation as "alpha". (FWIW, I managed to crash that as well, but only tested on 3.3 very briefly.)

I'm not sure how busy y'all are with other things these days; feel free to tell me to go away, send further info, etc., depending.

thank you very kindly for reading this far; any advice would be welcome.
-A-