Abort error

[GoogleCodeExporter]

I don't think this is error number 6, since this is with the latest version
of the code.

When I tried ./skipfish -o /var/tmp/out -W dictionaries/complete.wl
http://192.168.1.1

I got this error:

skipfish version 1.19b by <lcamtuf@google.com>
*** glibc detected *** ./skipfish: realloc(): invalid pointer:
0x0000000002101420 ***
======= Backtrace: =========
/lib/libc.so.6[0x7f75d490ed16]
/lib/libc.so.6[0x7f75d49150c5]
./skipfish[0x40bff2]
./skipfish[0x40e0bb]
./skipfish[0x40e28a]
./skipfish[0x403123]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7f75d48bcabd]
./skipfish[0x402369]
======= Memory map: ========
00400000-00429000 r-xp 00000000 08:12 21200950                          
/home/njh/Download/skipfish/skipfish
00628000-00629000 rw-p 00028000 08:12 21200950                          
/home/njh/Download/skipfish/skipfish
00629000-0062a000 rw-p 00000000 00:00 0
02100000-02121000 rw-p 00000000 00:00 0                                  [heap]
7f75d4484000-7f75d449a000 r-xp 00000000 08:06 3407913                   
/lib/libgcc_s.so.1
7f75d449a000-7f75d4699000 ---p 00016000 08:06 3407913                   
/lib/libgcc_s.so.1
7f75d4699000-7f75d469a000 rw-p 00015000 08:06 3407913                   
/lib/libgcc_s.so.1
7f75d469a000-7f75d469c000 r-xp 00000000 08:06 3408113                   
/lib/libdl-2.10.2.so
7f75d469c000-7f75d489c000 ---p 00002000 08:06 3408113                   
/lib/libdl-2.10.2.so
7f75d489c000-7f75d489d000 r--p 00002000 08:06 3408113                   
/lib/libdl-2.10.2.so
7f75d489d000-7f75d489e000 rw-p 00003000 08:06 3408113                   
/lib/libdl-2.10.2.so
7f75d489e000-7f75d49e8000 r-xp 00000000 08:06 3408094                   
/lib/libc-2.10.2.so
7f75d49e8000-7f75d4be8000 ---p 0014a000 08:06 3408094                   
/lib/libc-2.10.2.so
7f75d4be8000-7f75d4bec000 r--p 0014a000 08:06 3408094                   
/lib/libc-2.10.2.so
7f75d4bec000-7f75d4bed000 rw-p 0014e000 08:06 3408094                   
/lib/libc-2.10.2.so
7f75d4bed000-7f75d4bf2000 rw-p 00000000 00:00 0
7f75d4bf2000-7f75d4c09000 r-xp 00000000 08:06 4180650                   
/usr/lib/libz.so.1.2.3.4
7f75d4c09000-7f75d4e08000 ---p 00017000 08:06 4180650                   
/usr/lib/libz.so.1.2.3.4
7f75d4e08000-7f75d4e09000 rw-p 00016000 08:06 4180650                   
/usr/lib/libz.so.1.2.3.4
7f75d4e09000-7f75d4e3a000 r-xp 00000000 08:06 4181738                   
/usr/lib/libidn.so.11.6.1
7f75d4e3a000-7f75d503a000 ---p 00031000 08:06 4181738                   
/usr/lib/libidn.so.11.6.1
7f75d503a000-7f75d503b000 rw-p 00031000 08:06 4181738                   
/usr/lib/libidn.so.11.6.1
7f75d503b000-7f75d5089000 r-xp 00000000 08:06 4186090                   
/usr/lib/libssl.so.0.9.8
7f75d5089000-7f75d5289000 ---p 0004e000 08:06 4186090                   
/usr/lib/libssl.so.0.9.8
7f75d5289000-7f75d5290000 rw-p 0004e000 08:06 4186090                   
/usr/lib/libssl.so.0.9.8
7f75d5290000-7f75d5404000 r-xp 00000000 08:06 4184592                   
/usr/lib/libcrypto.so.0.9.8
7f75d5404000-7f75d5604000 ---p 00174000 08:06 4184592                   
/usr/lib/libcrypto.so.0.9.8
7f75d5604000-7f75d562c000 rw-p 00174000 08:06 4184592                   
/usr/lib/libcrypto.so.0.9.8
7f75d562c000-7f75d5630000 rw-p 00000000 00:00 0
7f75d5630000-7f75d564d000 r-xp 00000000 08:06 3407962                   
/lib/ld-2.10.2.so
7f75d5829000-7f75d582d000 rw-p 00000000 00:00 0
7f75d5847000-7f75d584c000 rw-p 00000000 00:00 0
7f75d584c000-7f75d584d000 r--p 0001c000 08:06 3407962                   
/lib/ld-2.10.2.so
7f75d584d000-7f75d584e000 rw-p 0001d000 08:06 3407962                   
/lib/ld-2.10.2.so
7fffb41b7000-7fffb41cd000 rw-p 00000000 00:00 0                         
[stack]
7fffb41ff000-7fffb4200000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                 
[vsyscall]
Aborted (core dumped)
njh@packard:~/Download/skipfish$

The gdb backtrace is:

#0  0x00007f75d48cff45 in *__GI_raise (sig=<value optimized out>)
   at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007f75d48d2d80 in *__GI_abort () at abort.c:88
#2  0x00007f75d490554d in __libc_message (do_abort=2,
   fmt=0x7fffb41c9c90 ' ' <repeats 23 times>,
"[stack]\n7fffb41ff000-7fffb4200000 r-xp 00000000 00:00 0", ' ' <repeats 26
times>, "[vdso]\nffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0",
' ' <repeats 18 times>, "[vsyscall]\n:06 4"...) at
../sysdeps/unix/sysv/linux/libc_fatal.c:173
#3  0x00007f75d490ed16 in malloc_printerr (action=3,
   str=0x7f75d49b6baf "realloc(): invalid pointer", ptr=<value optimized out>)
   at malloc.c:6239
#4  0x00007f75d49150c5 in realloc_check (oldmem=0x2101420, bytes=16,
   caller=<value optimized out>) at hooks.c:330
#5  0x000000000040bff2 in __DFL_ck_realloc (orig=0x2101420, size=5665)
   at alloc-inl.h:91
#6  0x000000000040e0bb in wordlist_confirm_single (text=<value optimized out>,
   is_ext=<value optimized out>, add_hits=<value optimized out>, total_age=2,
   last_age=2) at database.c:841
#7  0x000000000040e28a in load_keywords (fname=<value optimized out>,
   purge_age=0) at database.c:976
#8  0x0000000000403123 in main (argc=6, argv=0x7fffb41ca758) at skipfish.c:398

Original issue reported on code.google.com by fumeoftheday on 24 Mar 2010 at 12:14

[GoogleCodeExporter]

Does it reproduce reliably? Can you try with 'make clean debug' and redirect
2>logfile.txt, and see if it happens again? Also, regardless of the outcome, 
please
then try "grep ALLOC logfile.txt".

Original comment by lcam...@google.com on 24 Mar 2010 at 5:08

[GoogleCodeExporter]

Yes it is happens all the time.

njh@packard:~/Download/skipfish$ fgrep ALLOC logfile.txt 
njh@packard:~/Download/skipfish$ ls -l logfile.txt 
-rw-r--r-- 1 njh njh 0 Mar 24 17:21 logfile.txt
njh@packard:~/Download/skipfish$ 

Original comment by fumeoftheday on 24 Mar 2010 at 5:23

[GoogleCodeExporter]

The logfile has a size of 0, which suggests it's not generated for a 'make clean
debug' build? Can you verify?

Original comment by lcam...@google.com on 24 Mar 2010 at 6:25

[GoogleCodeExporter]

Oh wait, this happens during load_keywords(), never mind. Can you provide me 
with a 
gdb backtrace for the 'make clean debug' target, though?

Cheers,
/mz

Original comment by lcam...@gmail.com on 24 Mar 2010 at 6:48

[GoogleCodeExporter]

Specifically, I would be interesting with the output of these commands in gdb 
against 
a *debug* build:

back
p extension_cnt

Unfortunately, I can't reproduce this locally, so I am also wondering what OS / 
distro you happen to be using?

Original comment by lcam...@gmail.com on 24 Mar 2010 at 6:55

[GoogleCodeExporter]

(gdb) back
#0  0x00007f9abc51bf45 in *__GI_raise (sig=<value optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007f9abc51ed80 in *__GI_abort () at abort.c:88
#2  0x00007f9abc55154d in __libc_message (do_abort=2, 
    fmt=0x7fff0e3513c0 ' ' <repeats 23 times>, "[stack]\n7fff0e3ff000-7fff0e400000
r-xp 00000000 00:00 0", ' ' <repeats 26 times>,
"[vdso]\nffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0", ' ' <repeats 
18
times>, "[vsyscall]\n:06 4"...) at ../sysdeps/unix/sysv/linux/libc_fatal.c:173
#3  0x00007f9abc55ad16 in malloc_printerr (action=3, 
    str=0x7f9abc602baf "realloc(): invalid pointer", ptr=<value optimized out>)
    at malloc.c:6239
#4  0x00007f9abc5610c5 in realloc_check (oldmem=0x172a480, bytes=16, 
    caller=<value optimized out>) at hooks.c:330
#5  0x0000000000412700 in __DFL_ck_realloc (orig=0x172a480, size=5065, 
    func=0x432210 "wordlist_confirm_single", line=841, 
    file=<value optimized out>) at alloc-inl.h:91
#6  __AD_ck_realloc (orig=0x172a480, size=5065, 
    func=0x432210 "wordlist_confirm_single", line=841, 
    file=<value optimized out>) at alloc-inl.h:258
#7  0x00000000004134f1 in wordlist_confirm_single (text=0x7fff0e351c90 "asmx", 
    is_ext=<value optimized out>, add_hits=<value optimized out>, total_age=2, 
    last_age=<value optimized out>) at database.c:841
#8  0x000000000041370a in load_keywords (fname=<value optimized out>, 
---Type <return> to continue, or q <return> to quit---
    purge_age=0) at database.c:976
#9  0x0000000000403939 in main (argc=6, argv=0x7fff0e351eb8) at skipfish.c:398
(gdb) p extension_cnt
$1 = 1
(gdb)

This is on Debian 5. The output of 'uname -a' is:

Linux packard 2.6.32-3-amd64 #1 SMP Wed Feb 24 18:07:42 UTC 2010 x86_64 
GNU/Linux

Original comment by fumeoftheday on 25 Mar 2010 at 9:08

[GoogleCodeExporter]

This crash doesn't really make much sense to me. It's essentially crashing 
immediately upon start when reading the second line in the supplied dictionary. 
Very 
little is happening in the code prior to this point, so it's hard to imagine 
what 
could be wrong; and you are the only person reporting this issue so far, 
despite 50k+ 
downloads.

I will keep this bug open, but not being able to reproduce or figure out where 
that 
pointer came from means I might have to close it if no other reports surface.

Original comment by lcam...@gmail.com on 25 Mar 2010 at 5:41

[GoogleCodeExporter]

Ok. I tracked this down to MALLOC_CHECK_ being apparently set on your system. 
Version 
1.26 should be able to account for this.

Original comment by lcam...@gmail.com on 26 Mar 2010 at 6:54

• Changed state: Fixed

[GoogleCodeExporter]

Yes, malloc_check_ IS set to 3 on my system.

Original comment by fumeoftheday on 26 Mar 2010 at 9:08

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I just tried it on version 1.26b and I got the same crash.

Original comment by fumeoftheday on 29 Mar 2010 at 11:02

[GoogleCodeExporter]

Please set MALLOC_CHECK_ to 0 manually before executing the tool and let me 
know if 
this helps.

Original comment by lcam...@gmail.com on 29 Mar 2010 at 4:05

[GoogleCodeExporter]

Still crashes.

I am compiling with -fstack-protector, if that helps.

Original comment by fumeoftheday on 29 Mar 2010 at 4:24

[GoogleCodeExporter]

Huh? Why? Did you modify the Makefile manually? Were any other options added to 
CFLAGS? If yes, can you let me know if you are still seeing problems when you 
remove 
them?

Original comment by lcam...@gmail.com on 29 Mar 2010 at 5:12

[GoogleCodeExporter]

It comes in from CFLAGS.

If I disable it I no longer get a crash, so it looks as though you have a buffer
overflow problem somewhere.

Original comment by fumeoftheday on 30 Mar 2010 at 9:05

[GoogleCodeExporter]

Did you have anything else in CFLAGS, or just -fstack-protector?

The crash seems unrelated to the mechanism, which is odd.

Original comment by lcam...@gmail.com on 30 Mar 2010 at 3:43

[GoogleCodeExporter]

njh@packard:~$ echo $CFLAGS
-O2 -W -Wformat=2 -Wswitch -Wshadow -Wwrite-strings -Wuninitialized -Wall -pipe
-mtune=core2 -march=core2 -fomit-frame-pointer -ffast-math -msse2 -msse -mmmx
-mfpmath=sse -pedantic -D_FORTIFY_SOURCE=2 -Wpointer-arith -Wstrict-prototypes
-fstack-protector -Wstack-protector -Wextra -Wbad-function-cast -Wcast-align
-Wcast-qual -Wdisabled-optimization -Wendif-labels -Wfloat-equal 
-Wformat-nonliteral
-Winline -Wmissing-declarations -Wmissing-prototypes -Wnested-externs 
-Wpointer-arith
-Wundef -Wformat-security

Original comment by fumeoftheday on 30 Mar 2010 at 3:45

[GoogleCodeExporter]

OK, I believe your problem is -D_FORTIFY_SOURCE=2. It's a bug in FORTIFY_SOURCE 
in
GCC, not in skipfish.

It would have helped troubleshoot this problem if you described these 
non-standard
tweaks to your system (MALLOC_CHECK, FORTIFY_SOURCE, -fstack-protector, etc) up 
front.

I will have a tweak in 1.27 to reorder CFLAGS to always force FORTIFY_SOURCE 
off.

/mz

Original comment by lcam...@google.com on 30 Mar 2010 at 3:55