Author Topic: Bug in 3.0's new unique_mapping()  (Read 4734 times)

Offline FallenTree

  • BFF
  • ***
  • Posts: 484
    • View Profile
Re: Bug in 3.0's new unique_mapping()
« Reply #15 on: August 12, 2013, 01:53:07 AM »
ok, I think I've figured out the unique_mapping bug, it will happen if you returns a new mapping/array/object/string in the callback. 

please do a git pull, it should be included in the alpha7.3

We should continue on that copy_chars bug,  please report back if after alpha7.3 it is still there (i bet it does).

Offline Stavros

  • Acquaintance
  • *
  • Posts: 36
    • View Profile
Re: Bug in 3.0's new unique_mapping()
« Reply #16 on: August 12, 2013, 04:12:47 PM »
Yes, the telnet bug is still present in alpha7.3. The trace looks the same as far as I can tell, but I'll paste it anyway, just in case:

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


Event backend in use: epoll

Loading preloaded files ...
]Preloading: /adm/daemon/ftpd/ftpdt...](0.0)
]Preloading: /adm/daemon/services...](0.0)
]Preloading: /adm/daemon/intermud...](0.0)
Accepting connections on 127.0.0.1:6666.
Accepting connections on 127.0.0.1:4001.
Socket passed to fd 6 ignored (support is disabled).
Initializations complete.

==5231== Conditional jump or move depends on uninitialised value(s)
==5231==    at 0x462DA0: copy_chars(interactive_s*, char*, int) (comm.cc:1002)
==5231==    by 0x4649D2: get_user_data(interactive_s*) (comm.cc:1403)
==5231==    by 0x4AC875: on_user_read(int, short, void*) (event.cc:82)
==5231==    by 0x52840E3: event_base_loop (in /usr/lib64/libevent-2.0.so.5.1.9)
==5231==    by 0x4AC6FF: run_for_at_most_one_second(event_base*) (event.cc:65)
==5231==    by 0x451525: backend(event_base*) (backend.cc:131)
==5231==    by 0x432B7F: main (main.cc:390)
==5231==  Uninitialised value was created by a stack allocation
==5231==    at 0x461FB7: copy_chars(interactive_s*, char*, int) (comm.cc:687)
==5231==
==5231==
==5231== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- ==5231== starting debugger with cmd: /usr/bin/gdb -nw /proc/5235/fd/1024 5235
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/5235/fd/1024...done.
Attaching to program: /proc/5235/fd/1024, process 5235
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/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.6.3/libstdc++.so.6...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.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.6.3/libgcc_s.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.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/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/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.
0x0000000000462da0 in copy_chars (ip=0x6dfe860, from=0x7feffc510 "\377\372\030", num_bytes=75) at comm.cc:1002
1002                   if (env_buf[j]) { j++; }
[?1034h(gdb) bt
#0  0x0000000000462da0 in copy_chars (ip=0x6dfe860, from=0x7feffc510 "\377\372\030", num_bytes=75) at comm.cc:1002
#1  0x00000000004649d3 in get_user_data (ip=0x6dfe860) at comm.cc:1403
#2  0x00000000004ac876 in on_user_read (fd=12, what=2, arg=0x6e00a90) at event.cc:82
#3  0x00000000052840e4 in event_base_loop () from /usr/lib64/libevent-2.0.so.5
#4  0x00000000004ac700 in run_for_at_most_one_second (base=0x63d4f40) at event.cc:65
#5  0x0000000000451526 in backend (base=0x63d4f40) at backend.cc:131
#6  0x0000000000432b80 in main (argc=3, argv=0x7ff000028) at main.cc:390
(gdb) info locals
j = 0
k = 2
env_buf = "\340\273s\000\000\000\000\000\200\274s\000\000\000\000\000\214\305\342\005\000\000\000\000\340\064+\006\000\000\000\000d\300\377\376\a\000\000\000r)\321\005\000\000\000\000\202\002M\000\000\000\000\000\220\273s\000\000\000\000\000b\002M\000\000\000\000\000\300\273s\000\000\000\000\000лs\000\000\000\000\000\300\273s\000\000\000\000\000\340\300\377\376*(\000\000 \243*\006\000\000\000\000\220\273s\000\000\000\000\000лs\000\000\000\000\000\r8M\000\000\000\000\060h\340\337\006\000\000\000\000\020\274s\000\000\000\000\000\260\273s\000\000\000\000\000`\275\377\376\a\000\000\000_#I\000\000\000\000\000p\273s\000\000\000\000\000\020\000\000\000\060\000\000\000\r8M\000\000\000\000\000h\346\213\a\000\000\000\000\000\275\377\376\a\000\000\000\061\034I\000\000\000\000\000\002\021\000\000\000\000\000\000\240\227\002\070\000\000\000\000\002\000\000\000\000\000\000\000"...
i = 74
dont_response = "\377\376"
start = 0
x = 0
wont_response = "\377", <incomplete sequence \374>
(gdb) up
#1  0x00000000004649d3 in get_user_data (ip=0x6dfe860) at comm.cc:1403
1403       copy_chars(ip, buf, num_bytes);
(gdb) print *ip
$1 = {ob = 0x78934e0, input_to = 0x78be5e0, carryover = 0x0, num_carry = 0, connection_type = 1, fd = 12, addr = {ss_family = 2, __ss_align = 0, __ss_padding = 'u' <repeats 112 times>}, addrlen = 16,
  local_port = 6666, external_port = 0, prompt = 0x4d47ac "> ", text = "\000", 'u' <repeats 2047 times>, text_end = 0, text_start = 0, last_time = 1376341501, snooped_by = 0x0, default_err_message = {
    f = 0x0, s = 0x0}, ed_buffer = 0x0, message_producer = 1493, message_consumer = 1493, message_length = 0,
  message_buf = "\377\375\030\377\375\037\377\375[\377\373F\377\373]\377\375'\377\373\311", ' ' <repeats 16 times>, "A long time ago, in a galaxy far, far away...\r\n\r\n", ' ' <repeats 13 times>, '#' <repeats 24 times>, "   ######     ", '#' <repeats 11 times>, ' ' <repeats 15 times>, "\r\n", ' ' <repeats 11 times>, '#' <repeats 26 times>, "  ########    ", '#' <repeats 13 times>, "\r\n          ", '#' <repeats 27 times>, " ####  ####   "..., iflags = 1072, out_of_band = 0 '\000', state = 0, sb_pos = 51, trans = 0x6549a40, sb_buf = 0x6e00a10 "'", sb_size = 57, slc = {"\000",
     <incomplete sequence \363>,  <incomplete sequence \364>,  <incomplete sequence \365>,  <incomplete sequence \366>, "\000", "\000", "\000",  <incomplete sequence \355>, "\001\b", "\000", "\000",
    "\000", "\000", "\000", "\000", "\000", "\000"}, ws_text = 'u' <repeats 2048 times>, ws_text_end = 0, ws_text_start = 0, ws_size = 0, ws_mask = 1970632053, ws_maskoffs = 117 'u',
  ev_read = 0x6e00ae0, ev_write = 0x6e00c10, ev_data = 0x6e00a90}
(gdb) print buf
$2 = "\377\372\030\000XTERM-256COLOR\377\360\377\372'\000\003XAUTHORITY\001/home/cpl/.Xauthority\000DISPLAY\001roast:0\377\360\000/\000\000\000\377\377\377\377\000\000\000\000\062\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000 T\006\006", '\000' <repeats 12 times>"\220, \307\034\002\000\000\000\000\001\000\000\000\000\000\000\000\244\201\000\000\350\003\000\000\352\003", '\000' <repeats 14 times>, "Z\025\000\000\000\000\000\000\000\020\000\000\000\000\000\000\020\000\000\000\000\000\000\000\363#\bR\000\000\000\000\031\316Y\004\000\000\000\000\000\002\000\000\000\000\000\000\060\306\377\376\a\000\000\000\200X=\006\000\000\000\000\001", '\000' <repeats 23 times>...
(gdb) print num_bytes
$3 = 75

Again, this is immediately after connecting, no keyboard input at all.

I also have another memory corruption bug that (I think) is not related to this one... I'll try to valgrind it and post it here.

Offline FallenTree

  • BFF
  • ***
  • Posts: 484
    • View Profile
Re: Bug in 3.0's new unique_mapping()
« Reply #17 on: August 12, 2013, 04:22:38 PM »
first.. was the unique_mapping() bug fixed?

Offline Stavros

  • Acquaintance
  • *
  • Posts: 36
    • View Profile
Re: Bug in 3.0's new unique_mapping()
« Reply #18 on: August 12, 2013, 04:26:00 PM »
Sorry, yes, that was probably the most important thing to say: the unique_mapping bug was definitely fixed.

Also, responding to another question you asked but I neglected to respond to: I'm definitely running in developer mode, I re-ran the build script after you asked just to make sure.

OK, here is the other memory corruption we found. This is alpha7.3, and I logged in with tinyfugue, so no telnet negotiation issue. Like the others, it's a very complicated code path in-lib, so I'm having trouble isolating it with a simple bit of LPC code. If I do manage to reduce it down, I'll post here.

As always, let me know what else you want me to try.

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


Event backend in use: epoll

Loading preloaded files ...
]Preloading: /adm/daemon/ftpd/ftpdt...](0.0)
]Preloading: /adm/daemon/services...](0.0)
]Preloading: /adm/daemon/intermud...](0.0)
Accepting connections on 127.0.0.1:6666.
Accepting connections on 127.0.0.1:4001.
Socket passed to fd 6 ignored (support is disabled).
Initializations complete.

==5286== Conditional jump or move depends on uninitialised value(s)
==5286==    at 0x43EEB3: eval_instruction(char*) (interpret.cc:3275)
==5286==    by 0x4419E7: apply_low(char const*, object_s*, int) (interpret.cc:4333)
==5286==    by 0x471EBB: f__call_other() (efuns_main.cc:249)
==5286==    by 0x440B9B: eval_instruction(char*) (interpret.cc:3848)
==5286==    by 0x4419E7: apply_low(char const*, object_s*, int) (interpret.cc:4333)
==5286==    by 0x471EBB: f__call_other() (efuns_main.cc:249)
==5286==    by 0x440B9B: eval_instruction(char*) (interpret.cc:3848)
==5286==    by 0x4419E7: apply_low(char const*, object_s*, int) (interpret.cc:4333)
==5286==    by 0x441A72: apply(char const*, object_s*, int, int) (interpret.cc:4368)
==5286==    by 0x4A9855: user_parser(char*) (add_action.cc:417)
==5286==    by 0x4A9A53: parse_command(char*, object_s*) (add_action.cc:495)
==5286==    by 0x46650C: process_input(interactive_s*, char*) (comm.cc:1937)
==5286==  Uninitialised value was created by a heap allocation
==5286==    at 0x4C2B4CB: malloc (vg_replace_malloc.c:270)
==5286==    by 0x432E88: xalloc(int) (main.cc:454)
==5286==    by 0x4527F3: int_allocate_empty_array(unsigned int) (array.cc:82)
==5286==    by 0x452EAB: explode_string(char const*, int, char const*, int) (array.cc:312)
==5286==    by 0x4740BF: f_explode() (efuns_main.cc:956)
==5286==    by 0x440B9B: eval_instruction(char*) (interpret.cc:3848)
==5286==    by 0x4419E7: apply_low(char const*, object_s*, int) (interpret.cc:4333)
==5286==    by 0x441A72: apply(char const*, object_s*, int, int) (interpret.cc:4368)
==5286==    by 0x4A9855: user_parser(char*) (add_action.cc:417)
==5286==    by 0x4A9A53: parse_command(char*, object_s*) (add_action.cc:495)
==5286==    by 0x46650C: process_input(interactive_s*, char*) (comm.cc:1937)
==5286==    by 0x466860: process_user_command() (comm.cc:2026)
==5286==
==5286==
==5286== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- ==5286== starting debugger with cmd: /usr/bin/gdb -nw /proc/5290/fd/1024 5290
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/5290/fd/1024...done.
Attaching to program: /proc/5290/fd/1024, process 5290
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/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.6.3/libstdc++.so.6...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.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.6.3/libgcc_s.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.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/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/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.
0x000000000043eeb3 in eval_instruction (p=0x6480443 "\017\004\201") at interpret.cc:3275
3275             if (arr->item[i].type == T_OBJECT &&
[?1034h(gdb) bt
#0  0x000000000043eeb3 in eval_instruction (p=0x6480443 "\017\004\201") at interpret.cc:3275
#1  0x00000000004419e8 in apply_low (fun=0x66f34c8 "more", ob=0x6480d60, num_arg=3) at interpret.cc:4333
#2  0x0000000000471ebc in f__call_other () at efuns_main.cc:249
#3  0x0000000000440b9c in eval_instruction (p=0x78857b0 "\r\341\001\r\261\001\002\003\300\301\302\ay") at interpret.cc:3848
#4  0x00000000004419e8 in apply_low (fun=0x66f34c8 "more", ob=0x78b90b0, num_arg=1) at interpret.cc:4333
#5  0x0000000000471ebc in f__call_other () at efuns_main.cc:249
#6  0x0000000000440b9c in eval_instruction (p=0x77de8c6 "@") at interpret.cc:3848
#7  0x00000000004419e8 in apply_low (fun=0x779ed58 "read_message", ob=0x77e1540, num_arg=1) at interpret.cc:4333
#8  0x0000000000441a73 in apply (fun=0x779ed58 "read_message", ob=0x77e1540, num_arg=1, where=1) at interpret.cc:4368
#9  0x00000000004a9856 in user_parser (buff=0x760540 <process_input(interactive_s*, char*)::buf> "read 4") at add_action.cc:417
#10 0x00000000004a9a54 in parse_command (str=0x760540 <process_input(interactive_s*, char*)::buf> "read 4", ob=0x78b90b0) at add_action.cc:495
#11 0x000000000046650d in process_input (ip=0x6dffdf0, user_command=0x6dffeb0 "read 4") at comm.cc:1937
#12 0x0000000000466861 in process_user_command () at comm.cc:2026
#13 0x0000000000451538 in backend (base=0x63d4f40) at backend.cc:136
#14 0x0000000000432b80 in main (argc=3, argv=0x7ff000028) at main.cc:390
(gdb) info locals
arr = 0x6463200
num_arg = 3
i = 1
real = 1.6967669645385098e-313
n = -1
lval = 0x6480e20
instruction = 72
offset = 37
expected_stack = 0x73bc30 <start_of_stack+336>

Offline FallenTree

  • BFF
  • ***
  • Posts: 484
    • View Profile
Re: Bug in 3.0's new unique_mapping()
« Reply #19 on: August 12, 2013, 04:34:38 PM »
The stack trace tells you *a lot*

==5286==  Uninitialised value was created by a heap allocation
==5286==    at 0x4C2B4CB: malloc (vg_replace_malloc.c:270)
==5286==    by 0x432E88: xalloc(int) (main.cc:454)
==5286==    by 0x4527F3: int_allocate_empty_array(unsigned int) (array.cc:82)
==5286==    by 0x452EAB: explode_string(char const*, int, char const*, int) (array.cc:312)
==5286==    by 0x4740BF: f_explode() (efuns_main.cc:956)

This value is created by the some call to "explode_string"

#1  0x00000000004419e8 in apply_low (fun=0x66f34c8 "more", ob=0x6480d60, num_arg=3) at interpret.cc:4333

The problem was in a apply callback called "more",  if you do " print *current_object" after "bt" you should be able to see which object was executing this function.

#10 0x00000000004a9a54 in parse_command (str=0x760540 <process_input(interactive_s*, char*)::buf> "read 4", ob=0x78b90b0) at add_action.cc:495

is it reliably triggered by command "read 4" ?  (or read some other number I presume).


Offline Stavros

  • Acquaintance
  • *
  • Posts: 36
    • View Profile
Re: Bug in 3.0's new unique_mapping()
« Reply #20 on: August 12, 2013, 04:57:39 PM »
The way to reliably trigger it is to post a message on our main message board with a subject, but no message body, then attempt to read the post.

But it only triggers the first time someone reads the post. After the crash, I can restart the driver, and read the post just fine. Also, if there's any text in the body of the post, it works no problem.

Like I said, difficult to reduce to a simple test case.:P

Here is the *current_object, not sure if it will help or not. We have a daemon that handles printing multiple pages of text to a player -- I think it's still left from the original lib (Nightmare 3, if memory serves). Looks like it's happening in there somewhere. I'll try to a bunch of other ways to use the more daemon, to see if anything else triggers it.

Code: [Select]
(gdb) print *current_object
$1 = {ref = 1, flags = 4096, obname = 0x794ecb0 "daemon/system/more_d", next_hash = 0x0, next_ch_hash = 0x0, load_time = 1376343604, next_reset = 1376345150, time_of_ref = 1376343651, prog = 0x79944e0,
  next_all = 0x78e8e90, prev_all = 0x64796c0, next_inv = 0x0, contains = 0x0, super = 0x0, interactive = 0x0, replaced_program = 0x0, shadowing = 0x0, shadowed = 0x0, sent = 0x0,
  next_hashed_living = 0x0, living_name = 0x0, uid = 0x7961290, euid = 0x7961290, stats = {domain = 0x64f45f0, author = 0x0}, pinfo = 0x0, variables = {{type = 32, subtype = 0, u = {
        string = 0x795a710 "\001", number = 127248144, real = 6.2868936447459941e-316, refed = 0x795a710, buf = 0x795a710, ob = 0x795a710, arr = 0x795a710, map = 0x795a710, fp = 0x795a710,
        lvalue = 0x795a710, ref = 0x795a710, lvalue_byte = 0x795a710 "\001", error_handler = 0x795a710}}}}

Offline FallenTree

  • BFF
  • ***
  • Posts: 484
    • View Profile
Re: Bug in 3.0's new unique_mapping()
« Reply #21 on: August 12, 2013, 05:17:04 PM »
Okay, for the copy_chars issue, I think i know what is going on now.  Your OS(is it linux?  what distro? ) 's language is probably not in English, and your environment variables have non-english character in it. 

can you do this on your command line?

"telnet"  (enter)
"environ list" (enter)

and let's see what is in there.  Any way, the fix is quite easy, i just want to make sure.

For second bug,
 
I guess in your more_d there is some area where it is likely doing something like

" string* arr = explode_string(xxxx)  "

then

"xxx->more(arr
  • )  "


I guess the problem maybe caused by passing explode_string with a empty string, i will take a look at the code.

Offline Stavros

  • Acquaintance
  • *
  • Posts: 36
    • View Profile
Re: Bug in 3.0's new unique_mapping()
« Reply #22 on: August 12, 2013, 05:47:59 PM »
Distro is Gentoo, and LANG is en_US.UTF-8. I'll put the entire environ list at the bottom of the post.

I think the problem with explode may actually be in read_file(). In the following examples, "/wizards/stavros/t" is a blank file (i.e. 0 chars).

Code: [Select]
eval string fc; fc = ""; return explode(fc, "\n");returns an empty array

Code: [Select]
eval string fc; fc = read_file("/wizards/stavros/t"); return fc;returns an empty string ("")

Code: [Select]
eval string fc; fc = read_file("/wizards/stavros/t"); return explode(fc, "\n");crashes the driver, with a valgrind trace substantially the same as the one you've already seen

Code: [Select]
eval string fc; fc = read_file("/wizards/stavros/t"); return fc+"a";returns an empty string ("")

So the string returned by read_file() on a blank file are not acting the same as regular strings, for some reason.

UPDATE: Also, sizeof(fc) returns 1 when I read a blank file.

Here is the output from telnet:
Code: [Select]
telnet> environ list
  _                    /usr/bin/telnet
  OPENCL_PROFILE       nvidia
* XAUTHORITY           /home/cpl/.Xauthority
  CONFIG_PROTECT       /usr/share/gnupg/qualified.txt
  OPENGL_PROFILE       nvidia
* DISPLAY              roast:0
  WINDOWPATH           7
  INFOPATH             /usr/share/info:/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/info:/usr/share/binutils-data/x86_64-pc-linux-gnu/2.23.1/info
  LESSOPEN             |lesspipe %s
  XDG_DATA_DIRS        /usr/local/share:/usr/share
  GCC_SPECS           
  PYTHONPATH           :/usr/local/lib/python2.6/site-packages:/usr/local/lib/python2.6/site-packages
  LESS                 -R -M --shift 5
  LOGNAME              cpl
  JDK_HOME             /etc/java-config-2/current-system-vm
  SHLVL                5
  HOME                 /home/cpl
  QT_GRAPHICSSYSTEM    raster
  LANG                 en_US.UTF-8
  JAVAC                /etc/java-config-2/current-system-vm/bin/javac
  EDITOR               /usr/bin/vi
  JAVA_HOME            /etc/java-config-2/current-system-vm
  PWD                  /home/cpl
  HG                   /usr/bin/hg
  MAIL                 /var/mail/cpl
  PATH                 /usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3:/usr/games/bin:/home/cpl/bin:/home/cpl/bin
  XDG_CONFIG_DIRS      /etc/xdg
  PAGER                /usr/bin/less
  CONFIG_PROTECT_MASK  /etc/gentoo-release /etc/sandbox.d /etc/fonts/fonts.conf /etc/terminfo /etc/ca-certificates.conf /etc/texmf/web2c /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/revdep-rebuild
  MULTIOSDIRS          ../lib64:../lib32
  LS_COLORS            rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=0
1;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.
jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*
.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=0
1;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;
35:*.ogv=01;35:*.ogx=01;35:*.pdf=00;32:*.ps=00;32:*.txt=00;32:*.patch=00;32:*.diff=00;32:*.log=00;32:*.tex=00;32:*.doc=00;32:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg
=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:
  PRELINK_PATH_MASK    /usr/lib64/libfreebl3.so:/usr/lib64/libnssdbm3.so:/usr/lib64/libsoftokn3.so
  USER                 cpl
  HUSHLOGIN            FALSE
  WINDOWID             29360129
  SHELL                /bin/bash
+ TERM                 xterm-256color
  XDG_DATA_HOME        /home/cpl/.config
  MANPATH              /etc/java-config-2/current-system-vm/man:/usr/local/share/man:/usr/share/man:/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/man:/usr/share/binutils-data/x86_64-pc-linux-gnu/2.23.1/man:/etc/java-config-2/cu
rrent-system-vm/man/
« Last Edit: August 12, 2013, 05:57:12 PM by Stavros »

Offline FallenTree

  • BFF
  • ***
  • Posts: 484
    • View Profile
Re: Bug in 3.0's new unique_mapping()
« Reply #23 on: August 12, 2013, 07:16:11 PM »
OK. I think I've figured out copy_chars bug, to be sure, can you do "print ip->sb_buf[k] ' on the gdb?    just reproduce this bug with telnet, then drop into gdb, and put that command. 

If I am right, the value should be '3'.  Your telnet is sending a USERVAR type for XAUTHORITY variable, which driver doesn't understand!!! it only understand type 0 , normal VAR..  damn it. this bug is since first of fluffos 2.x release.....(my telnet client send everything as type 0)..

Offline Stavros

  • Acquaintance
  • *
  • Posts: 36
    • View Profile
Re: Bug in 3.0's new unique_mapping()
« Reply #24 on: August 12, 2013, 07:20:29 PM »
Yep, it's 3.

Code: [Select]
(gdb) print ip->sb_buf[k]
$1 = 3 '\003'

Offline FallenTree

  • BFF
  • ***
  • Posts: 484
    • View Profile
Re: Bug in 3.0's new unique_mapping()
« Reply #25 on: August 12, 2013, 08:43:39 PM »
OKAY.  both fixes has been submitted. please do a git pull and let me know what happens.

since this thread is going a bit long, if there is more problem you discovered, please open a new thread.

Offline Stavros

  • Acquaintance
  • *
  • Posts: 36
    • View Profile
Re: Bug in 3.0's new unique_mapping()
« Reply #26 on: August 12, 2013, 09:15:16 PM »
Yes, that got both the telnet issue and the read_file() issue. I'm going to run around in our lib trying to break things, but I think you got all of the outstanding issues we've found so far. Thanks again!