Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Stavros

Pages: [1]
1
Drivers / addr data lost during connection
« on: July 22, 2014, 09:24:22 AM »
Still working on figuring out exactly what is happening and how, but:

In async_on_accept(), as "user" (an interactive_t) is being populated, addr is not set.

Somehow, this translates to all users' IP showing up as the server's IP.

You can see this by doing -devent (shows correct IP in on_external_port_event ()), then -dconnections (shows server IP address in new_user_handler ()).

Further updates as I work on it later tonight.

Can anyone else confirm this problem? Should be easy enough... Compare the query_ip_number() of your players to your server IP.

2
Drivers / restoring go-ahead after write_prompt
« on: July 20, 2014, 10:22:32 PM »
When the switch was made to libtelnet (commit a901c645), one bit of code that was removed was sending a go-ahead (TELNET_GA) command after each prompt. A lot of clients use this command to differentiate prompts from other text. Here is a small patch to add it back in, but using the libtelnet API:

Code: [Select]
diff --git a/src/comm.cc b/src/comm.cc
index 0754d70..4e5c4a3 100644
--- a/src/comm.cc
+++ b/src/comm.cc
@@ -1371,6 +1371,9 @@ static void print_prompt(interactive_t *ip) {
   if (!IP_VALID(ip, ob)) {
     return;
   }
+  if ((ip->iflags & USING_TELNET) && !(ip->iflags & SUPPRESS_GA)) {
+    telnet_iac(ip->telnet, TELNET_GA);
+  }
 } /* print_prompt() */

 /*

3
Drivers / bug with call_out and shadows
« on: November 23, 2013, 10:03:03 AM »
Here is one of the issues we've run into. Looks like an infinite loop in certain situations. I think this patch fixes it, but I'll leave it up to Fallentree to say for sure.  :)

Code: [Select]
diff --git a/src/call_out.cc b/src/call_out.cc
index ed1bd51..cbef2d1 100644
--- a/src/call_out.cc
+++ b/src/call_out.cc
@@ -170,9 +170,9 @@ void call_out(pending_call_t *cop)
   }
 
 #ifndef NO_SHADOWS
-  if (cop->ob)
-    while (cop->ob->shadowing) {
-      ob = cop->ob->shadowing;
+  if (ob)
+    while (ob->shadowing) {
+      ob = ob->shadowing;
     }
 #endif
   new_command_giver = 0;

4
Drivers / memory corruption bug
« on: October 02, 2013, 07:17:53 PM »
I'm running on the latest commit from next-3.0 (commit sha1: e4a961d6d1f033ea8bd40c8ddec96d953b6eb81a).

We crashed about 2 hours after moving our live mud to the new driver. We've reverted to 2.x, and I've been trying to figure out what actually caused the crash. I've had to resort to writing a tool to load all .c files in a given directory.

While using this tool, I ran into a memory corruption bug -- I'm not sure if this is the bug that crashed our mud or not.

To actually cause the bug, I'm starting the MUD, logging in, and running my directory loader recursively on a directory big enough to cause it to time out. It doesn't matter if the time out is set for 10 seconds or an hour, and it doesn't seem to matter what file I'm actually on. When I actually hit the execution time out while loading lots of files, it does this:

Code: [Select]
==9959== Memcheck, a memory error detector
==9959== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==9959== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==9959== Command: ./driver Config.SW
==9959==
WARNING: rlimit for core dump is 0, you will not get core on crash.
using config file: Config.SW
----------------------------------------------------------------------------
SWmud (FluffOS v3.0-alpha7.4) starting up on Linux/x86-64 - Wed Oct  2 14:39:07 2013


Event backend in use: epoll

Loading preloaded files ...
Accepting connections on [::ffff:127.0.0.1]:6666.
Accepting connections on [::ffff:127.0.0.1]:4001.
Socket passed to fd 6 ignored (support is disabled).
Initializations complete.

object /d/afel/mon/droid_vendor: eval_cost too big 10000000
==9959== Conditional jump or move depends on uninitialised value(s)
==9959==    at 0x493C30: f_undefinedp() (efuns_main.cc:3736)
==9959==    by 0x454FB8: eval_instruction(char*) (interpret.cc:3851)
==9959==    by 0x4C5C6E: call_function_pointer(funptr_s*, int) (function.cc:327)
==9959==    by 0x44952C: call_efun_callback(function_to_call_t*, int) (interpret.cc:602)
==9959==    by 0x46D252: map_array(svalue_s*, int) (array.cc:1082)
==9959==    by 0x48DAFC: f_map() (efuns_main.cc:1541)
==9959==    by 0x454FB8: eval_instruction(char*) (interpret.cc:3851)
==9959==    by 0x4C5C6E: call_function_pointer(funptr_s*, int) (function.cc:327)
==9959==    by 0x44952C: call_efun_callback(function_to_call_t*, int) (interpret.cc:602)
==9959==    by 0x46D252: map_array(svalue_s*, int) (array.cc:1082)
==9959==    by 0x48DAFC: f_map() (efuns_main.cc:1541)
==9959==    by 0x454FB8: eval_instruction(char*) (interpret.cc:3851)
==9959==  Uninitialised value was created by a heap allocation
==9959==    at 0x93BD4CB: malloc (vg_replace_malloc.c:270)
==9959==    by 0x446D82: xalloc(int) (main.cc:458)
==9959==    by 0x46A757: int_allocate_empty_array(unsigned int) (array.cc:82)
==9959==    by 0x46A7C2: allocate_empty_array(int) (array.cc:97)
==9959==    by 0x49273E: f_stat() (efuns_main.cc:3287)
==9959==    by 0x454FB8: eval_instruction(char*) (interpret.cc:3851)
==9959==    by 0x455EB5: apply_low(char const*, object_s*, int) (interpret.cc:4334)
==9959==    by 0x48A3B8: f__call_other() (efuns_main.cc:249)
==9959==    by 0x454FB8: eval_instruction(char*) (interpret.cc:3851)
==9959==    by 0x455EB5: apply_low(char const*, object_s*, int) (interpret.cc:4334)
==9959==    by 0x456008: apply(char const*, object_s*, int, int) (interpret.cc:4369)
==9959==    by 0x4C718D: user_parser(char*) (add_action.cc:417)
==9959==
==9959==
==9959== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- ==9959== starting debugger with cmd: /usr/bin/gdb -nw /proc/9978/fd/1024 9978
GNU gdb (Gentoo 7.5.1 p2) 7.5.1
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>...
Reading symbols from /proc/9978/fd/1024...done.
Attaching to program: /proc/9978/fd/1024, process 9978
Reading symbols from /usr/lib64/valgrind/vgpreload_core-amd64-linux.so...Reading symbols from /usr/lib64/debug/usr/lib64/valgrind/vgpreload_core-amd64-linux.so.debug...done.
done.
Loaded symbols for /usr/lib64/valgrind/vgpreload_core-amd64-linux.so
Reading symbols from /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so...Reading symbols from /usr/lib64/debug/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so.debug...done.
done.
Loaded symbols for /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so
Reading symbols from /lib64/librt.so.1...Reading symbols from /usr/lib64/debug/lib64/librt-2.15.so.debug...(no debugging symbols found)...done.
(no debugging symbols found)...done.
Loaded symbols for /lib64/librt.so.1
Reading symbols from /lib64/libpthread.so.0...Reading symbols from /usr/lib64/debug/lib64/libpthread-2.15.so.debug...(no debugging symbols found)...done.
(no debugging symbols found)...done.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Loaded symbols for /lib64/libpthread.so.0
Reading symbols from /lib64/libz.so.1...Reading symbols from /usr/lib64/debug/lib64/libz.so.1.2.7.debug...(no debugging symbols found)...done.
(no debugging symbols found)...done.
Loaded symbols for /lib64/libz.so.1
Reading symbols from /lib64/libcrypt.so.1...Reading symbols from /usr/lib64/debug/lib64/libcrypt-2.15.so.debug...(no debugging symbols found)...done.
(no debugging symbols found)...done.
Loaded symbols for /lib64/libcrypt.so.1
Reading symbols from /usr/lib64/libevent-2.0.so.5...(no debugging symbols found)...done.
Loaded symbols for /usr/lib64/libevent-2.0.so.5
Reading symbols from /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6...Reading symbols from /usr/lib64/debug/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6.0.17.debug...done.
done.
Loaded symbols for /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6
Reading symbols from /lib64/libm.so.6...Reading symbols from /usr/lib64/debug/lib64/libm-2.15.so.debug...(no debugging symbols found)...done.
(no debugging symbols found)...done.
Loaded symbols for /lib64/libm.so.6
Reading symbols from /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libgcc_s.so.1...Reading symbols from /usr/lib64/debug/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libgcc_s.so.1.debug...done.
done.
Loaded symbols for /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libgcc_s.so.1
Reading symbols from /lib64/libc.so.6...Reading symbols from /usr/lib64/debug/lib64/libc-2.15.so.debug...(no debugging symbols found)...done.
(no debugging symbols found)...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from /usr/lib64/debug/lib64/ld-2.15.so.debug...(no debugging symbols found)...done.
(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Failed to read a valid object file image from memory.
0x0000000000493c30 in f_undefinedp () at efuns_main.cc:3736
3736     if (!sp->u.number && (sp->subtype == T_UNDEFINED)) {
[?1h=(gdb) bt
[?1l>#0  0x0000000000493c30 in f_undefinedp () at efuns_main.cc:3736
#1  0x0000000000454fb9 in eval_instruction (p=0xae9aca5 "@") at interpret.cc:3851
#2  0x00000000004c5c6f in call_function_pointer (funp=0xaee5c80, num_arg=1) at function.cc:327
#3  0x000000000044952d in call_efun_callback (ftc=0x7feff2c80, n=1) at interpret.cc:602
#4  0x000000000046d253 in map_array (arg=0x75fb20 <start_of_stack+1152>, num_arg=2) at array.cc:1082
#5  0x000000000048dafd in f_map () at efuns_main.cc:1541
#6  0x0000000000454fb9 in eval_instruction (p=0xae9aca5 "@") at interpret.cc:3851
#7  0x00000000004c5c6f in call_function_pointer (funp=0xb5f79a0, num_arg=1) at function.cc:327
#8  0x000000000044952d in call_efun_callback (ftc=0x7feff34a0, n=1) at interpret.cc:602
#9  0x000000000046d253 in map_array (arg=0x75fab0 <start_of_stack+1040>, num_arg=2) at array.cc:1082
#10 0x000000000048dafd in f_map () at efuns_main.cc:1541
#11 0x0000000000454fb9 in eval_instruction (p=0xae9abc7 "@") at interpret.cc:3851
#12 0x00000000004569bf in call_direct (ob=0xae9fe50, offset=81, origin=8, num_arg=1) at interpret.cc:4625
#13 0x00000000004c0865 in call_simul_efun (index=80, num_arg=1) at eoperators.cc:1137
#14 0x0000000000454703 in eval_instruction (p=0xaef5f4c "D\003") at interpret.cc:3721
#15 0x00000000004569bf in call_direct (ob=0xaef6d50, offset=46, origin=1, num_arg=1) at interpret.cc:4625
#16 0x00000000004c4493 in apply_master_ob (fun=7, num_arg=1) at master.cc:30
#17 0x000000000045d2ad in mudlib_error_handler (err=0x7feff4460 "*Too long evaluation. Execution aborted.\n", katch=0) at simulate.cc:1797
#18 0x000000000045d584 in error_handler (err=0x7feff4460 "*Too long evaluation. Execution aborted.\n") at simulate.cc:1883
#19 0x000000000045d8e6 in error (fmt=0x4eeb40 "Too long evaluation. Execution aborted.\n") at simulate.cc:1964
#20 0x000000000044d3de in eval_instruction (p=0xc4f8e7c ".") at interpret.cc:2019
#21 0x0000000000456243 in call___INIT (ob=0xc4f9700) at interpret.cc:4427
#22 0x0000000000465a02 in call_create (ob=0xc4f9700, num_arg=0) at object.cc:2002
#23 0x000000000045a6de in int_load_object (lname=0x7feff6e00 "d/afel/mon/droid_vendor", callcreate=1) at simulate.cc:541
#24 0x000000000045a52e in int_load_object (lname=0x7feff73f0 "d/afel/mon/droid_vendor", callcreate=1) at simulate.cc:508
#25 0x000000000045ca15 in find_object (str=0xb2530b8 "/d/afel/mon/droid_vendor") at simulate.cc:1460
#26 0x000000000045a8df in clone_object (str1=0xb2530b8 "/d/afel/mon/droid_vendor", num_arg=0) at simulate.cc:587
#27 0x000000000048b292 in f__new () at efuns_main.cc:491
#28 0x0000000000454fb9 in eval_instruction (p=0xb25375e "\016,\003{") at interpret.cc:3851
#29 0x0000000000455eb6 in apply_low (fun=0xba75e28 "extra_reset", ob=0xb253bd0, num_arg=0) at interpret.cc:4334
#30 0x000000000048a3b9 in f__call_other () at efuns_main.cc:249
#31 0x0000000000454fb9 in eval_instruction (p=0xb3ab170 "\003{") at interpret.cc:3851
#32 0x0000000000455eb6 in apply_low (fun=0xba72c98 "reset", ob=0xb253bd0, num_arg=0) at interpret.cc:4334
#33 0x000000000048a3b9 in f__call_other () at efuns_main.cc:249
#34 0x0000000000454fb9 in eval_instruction (p=0xb3ab102 ".") at interpret.cc:3851
#35 0x0000000000455eb6 in apply_low (fun=0x4f18de "create", ob=0xb253bd0, num_arg=0) at interpret.cc:4334
#36 0x0000000000456009 in apply (fun=0x4f18de "create", ob=0xb253bd0, num_arg=0, where=1) at interpret.cc:4369
#37 0x0000000000465a39 in call_create (ob=0xb253bd0, num_arg=0) at object.cc:2009
#38 0x000000000045a6de in int_load_object (lname=0x7feffa880 "d/afel/lvl1/124", callcreate=1) at simulate.cc:541
#39 0x000000000045ca15 in find_object (str=0xb12d4e8 "/d/afel/lvl1/124.c") at simulate.cc:1460
#40 0x000000000048c7ca in f_find_object () at efuns_main.cc:1009
#41 0x0000000000454fb9 in eval_instruction (p=0xb76c820 "\017\004\200") at interpret.cc:3851
#42 0x0000000000455eb6 in apply_low (fun=0xb7814c8 "cmd_dload", ob=0xada52c0, num_arg=1) at interpret.cc:4334
#43 0x000000000048a3b9 in f__call_other () at efuns_main.cc:249
#44 0x0000000000454fb9 in eval_instruction (p=0xbda889f "\003\230") at interpret.cc:3851
#45 0x0000000000455eb6 in apply_low (fun=0xbd797a8 "cmd_hook", ob=0xc3a4cd0, num_arg=1) at interpret.cc:4334
#46 0x0000000000456009 in apply (fun=0xbd797a8 "cmd_hook", ob=0xc3a4cd0, num_arg=1, where=1) at interpret.cc:4369
#47 0x00000000004c718e in user_parser (buff=0x8774160 <process_input(interactive_s*, char*)::buf> "dload") at add_action.cc:417
#48 0x00000000004c7373 in parse_command (str=0x8774160 <process_input(interactive_s*, char*)::buf> "dload", ob=0xc3a4cd0) at add_action.cc:495
#49 0x000000000047e4fc in process_input (ip=0xb81f490, user_command=0xb81f550 "dload") at comm.cc:1932
#50 0x000000000047e8ac in process_user_command (ip=0xb81f490) at comm.cc:2026
#51 0x00000000004ca027 in on_user_command (fd=-1, what=1, arg=0xb8226e0) at event.cc:107
#52 0x0000000009e490e4 in event_base_loop () from /usr/lib64/libevent-2.0.so.5
#53 0x00000000004c9e28 in run_for_at_most_one_second (base=0xad7ffc0) at event.cc:66
#54 0x00000000004666d7 in backend (base=0xad7ffc0) at backend.cc:209
#55 0x0000000000446a7a in main (argc=2, argv=0x7feffffb8) at main.cc:394

Like I said, the actual object being loaded doesn't seem to matter. Where it actually has trouble is in the error handler. However, I haven't been able to find a simple piece of code that can be eval'd to cause the bug. I'm still trying to narrow it down.

Let me know if you want info from any of the frames.

Thanks,
Stav

5
Drivers / Bug in 3.0's new unique_mapping()
« on: August 10, 2013, 05:21:43 PM »
Hello,

The new unique_mapping() seems to have some problems. Here's a simple example:

eval return unique_mapping( ({ "alpha","bravo","charlie","apple","bongo","cat" }), (: $1[0..0] :) );

On my local test copy (running on a 64-bit system) it just mixes it up and puts in "a" words with "b" words, or vice-versa.

On our test environment on our actual server (running on a 32-bit system, unfortunately), it returns ([ "": "alpha" ]).

When you do an array of objects and have the return type of the function be a string, it gets even worse.

On my local copy (again, 64-bit), I ran "eval return unique_mapping(users(),(: $1->query_name() :))" a few times, then it stopped outputting anything and this spat out at the prompt:

*** glibc detected *** /home/stav/misc/mud/bin/driver: malloc(): memory corruption (fast): 0x000000000165a330 ***

When I run that eval on the 32-bit system, it was doing weird things like putting the date in for player names when using chat lines, etc.

I'll see if I can find out anything more with my own testing. If you want any sort of information from me, like build environments for any of the boxes I'm using, let me know and I'll get whatever you need. Also, if there is a different venue for bug reports that you would like me to use, please let me know.

On a side note, I'm really happy to see the work you guys are putting into the driver, we all really appreciate it.

Thanks,
Stavros

6
Drivers / patch for crasher in mapping.c
« on: July 03, 2011, 01:08:55 PM »
unique_mapping(arr,"some_func") crashes the driver when some_func doesn't exist in this_object(). I'm sure there's a way to test for the existence of the function before we enter the while loop, thus saving some CPU time, but I'm not familiar enough with the driver code to do it.

Patch:

Code: [Select]
diff -rupN ../fluffos-2.22-stock//mapping.c ./mapping.c
--- ../fluffos-2.22-stock//mapping.c 2011-02-14 16:10:06.000000000 -0500
+++ ./mapping.c 2011-07-03 12:40:49.000000000 -0400
@@ -631,6 +631,8 @@ void f_unique_mapping (void)
     while (size--) {
         push_svalue(v->item + size);
         sv = call_efun_callback(&ftc, 1);
+        if (!sv)
+            continue;
         i = (oi = svalue_to_int(sv)) & mask;
         if ((uptr = table[i])) {
             do {

7
Drivers / Patch to add atan2 to FluffOS
« on: August 03, 2010, 07:36:40 PM »
For those interested (heh), here is a patch to add atan2 to the math package in FluffOS. It's just the pow code copy/pasted, with atan2 stuck in for the actual C library call, since pow and atan2 have the same signature.

Copy/paste the code block below into a file in the FluffOS source dir, then "patch -p1 < patchfile".

Wodan or any other Fluff maintainers, if you're game I would love to have this added into the official driver so I wouldn't have to remind my admin to patch it back in every time we do a driver upgrade. :)

Stavros

Code: [Select]
diff -rupN fluffos-2.20-base/packages/math.c fluffos-2.20/packages/math.c
--- fluffos-2.20-base/packages/math.c   2010-04-22 13:54:10.000000000 -0500
+++ fluffos-2.20/packages/math.c        2010-08-03 19:46:49.000000000 -0500
@@ -85,6 +85,29 @@ f_atan (void)
 }
 #endif

+#ifdef F_ATAN2
+void
+f_atan2 (void)
+{
+    float val, val2;
+
+    if((sp-1)->type == T_NUMBER)
+        val = (float) (sp-1)->u.number;
+    else
+        val = (sp-1)->u.real;
+
+    if(sp->type == T_NUMBER)
+        val2 = (float) sp->u.number;
+    else
+        val2 = sp->u.real;
+
+
+    (sp - 1)->u.real = atan2(val, val2);
+    sp--;
+    sp->type = T_REAL;
+}
+#endif
+
 #ifdef F_SQRT
 void
 f_sqrt (void)
diff -rupN fluffos-2.20-base/packages/math_spec.c fluffos-2.20/packages/math_spec.c
--- fluffos-2.20-base/packages/math_spec.c      2009-06-11 14:50:42.000000000 -0500
+++ fluffos-2.20/packages/math_spec.c   2010-08-03 19:45:14.000000000 -0500
@@ -6,6 +6,7 @@
     float asin(float);
     float acos(float);
     float atan(float);
+    float atan2(float|int, float|int);
     float sqrt(float|int);
     float log(float);
     float log10(float|int);

8
General / heart_beat v. call_out
« on: April 22, 2010, 12:14:51 PM »
OK, my question is, should I default to using heart_beat, or call_out? I've tried to do some research:

http://dead-souls.net/ds-creator-faq.html#2.36
The Dead Souls Creator FAQ says always use heart_beat.

http://dead-souls.net/docs/lpc/intermediate/chapter2
The omni-present LPC docs say it depends on the application. (see 2.4)

The "Performance" file in the root directory of FluffOS's source (couldn't find online copy) says not to give objects heartbeats unless really necessary, and to do as little in the heart_beat function as possible.

http://lpmuds.net/forum/index.php?topic=743.msg4308#msg4308
I was digging a little deeper, and I found mention of "hearbeat changes" that "should be spelled out gigantic letters" but aren't... (last line of 2nd paragraph of linked post)

I couldn't find very much more on the subject of heart_beat changes with the standard google searches. The Changelogs of FluffOS weren't very informative either, at least to someone with my relatively limited knowledge of the driver.

So, heart_beat or call_out? And what are the heartbeat changes that everyone should know about? Or is there a doc out there that already covers all of this, but happens to be sitting right in one of blind spots?

Pages: [1]