Re: [Clamav-devel] Tests failing on FreeBSD 6.x

2010-03-04 Thread Renato Botelho
2010/3/1 Török Edwin edwinto...@gmail.com:
 On 03/01/2010 10:46 PM, Renato Botelho wrote:
 2010/3/1 Török Edwin edwinto...@gmail.com:
 On 03/01/2010 09:22 PM, Renato Botelho wrote:
 Hello one more time,

 I was trying to update clamav-devel port to a more recent snapshot
 and I got some segfaults during make test, like you can see here:
 Which FreeBSD version, and which architecture?

 6.4-RELEASE amd64

 I have 6.4 i386 in a VM :(

 I just installed gcc42 on it (pkg_add needed some convincing to use
 packages-6-stable instead of packages-6.4-release), and llvmunittest_ADT
 worked.

 I did this:
 ./configure CXX=g++42 CC=gcc42 --disable-clamav --enable-llvm
 cd libclamav/c++
 make llvmunittest_ADT
 ./llvmunittest_ADT

 It told me that 92 tests passed.

 My guess is that something goes wrong during startup, the ADT test is
 really simple and tehre isn't much that can segfault there.


 Can you get a gdb backtrace for one of these? (when built with debug
 symbols)
 Just run gdb ./llvmunittest_ADT
 (gdb) run
 ...
 (gdb) bt

I got a real 6.4 amd64 machine, and i reproduced the problem,
here is the data i collected after build with -g:

testegw# gdb ./llvmunittest_ADT
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd...
(gdb) run
Starting program:
/home/garga/clamav-devel/work/clamav-devel-20100303/libclamav/c++/llvmunittest_ADT
[New LWP 100047]
[New Thread 0x60f000 (LWP 100047)]
[New LWP 100047]

Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 100047]
0x00080073931d in _pthread_mutex_trylock () from /usr/lib/libthr.so.2
(gdb) bt
#0  0x00080073931d in _pthread_mutex_trylock () from /usr/lib/libthr.so.2
#1  0x000800739686 in pthread_mutex_lock () from /usr/lib/libthr.so.2
#2  0x000800b740af in __register_frame_info_bases (begin=Variable
begin is not available.
) at gthr-posix.h:611
#3  0x000800b6c191 in frame_dummy () from /usr/local/lib/gcc42/libgcc_s.so.1
#4  0x in ?? ()
#5  0x000800b6bf01 in _init () from /usr/local/lib/gcc42/libgcc_s.so.1
#6  0x7fffeaf0 in ?? ()
#7  0x000800601e4d in _rtld_error () from /libexec/ld-elf.so.1
#8  0x000800604ac2 in _rtld () from /libexec/ld-elf.so.1
#9  0x000800601479 in .rtld_start () from /libexec/ld-elf.so.1
#10 0x in ?? ()
#11 0x in ?? ()
#12 0x in ?? ()
#13 0x in ?? ()
#14 0x0001 in ?? ()
#15 0x7fffeda0 in ?? ()
#16 0x in ?? ()
#17 0x7fffedf3 in ?? ()
#18 0x7fffedfd in ?? ()
#19 0x7fffee08 in ?? ()
#20 0x7fffee17 in ?? ()
#21 0x7fffee7d in ?? ()
#22 0x7fffee91 in ?? ()
#23 0x7fffee9d in ?? ()
#24 0x7fffeeb2 in ?? ()
#25 0x7fffeebd in ?? ()
#26 0x7fffeece in ?? ()
#27 0x7fffeedd in ?? ()

Let me know if you need something else.
-- 
Renato Botelho
___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net


Re: [Clamav-devel] Tests failing on FreeBSD 6.x

2010-03-04 Thread Török Edwin
On 03/04/2010 03:12 PM, Renato Botelho wrote:
 I got a real 6.4 amd64 machine, and i reproduced the problem,
 here is the data i collected after build with -g:

Did you set CXXFLAGS to -g? Setting CFLAGS has no effect on libclamav/c++

 
 testegw# gdb ./llvmunittest_ADT
 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain conditions.
 Type show copying to see the conditions.
 There is absolutely no warranty for GDB.  Type show warranty for details.
 This GDB was configured as amd64-marcel-freebsd...
 (gdb) run
 Starting program:
 /home/garga/clamav-devel/work/clamav-devel-20100303/libclamav/c++/llvmunittest_ADT
 [New LWP 100047]
 [New Thread 0x60f000 (LWP 100047)]
 [New LWP 100047]
 
 Program received signal SIGSEGV, Segmentation fault.
 [Switching to LWP 100047]
 0x00080073931d in _pthread_mutex_trylock () from /usr/lib/libthr.so.2
 (gdb) bt
 #0  0x00080073931d in _pthread_mutex_trylock () from /usr/lib/libthr.so.2
 #1  0x000800739686 in pthread_mutex_lock () from /usr/lib/libthr.so.2
 #2  0x000800b740af in __register_frame_info_bases (begin=Variable
 begin is not available.
 ) at gthr-posix.h:611
 #3  0x000800b6c191 in frame_dummy () from 
 /usr/local/lib/gcc42/libgcc_s.so.1
 #4  0x in ?? ()
 #5  0x000800b6bf01 in _init () from /usr/local/lib/gcc42/libgcc_s.so.1
 #6  0x7fffeaf0 in ?? ()
 #7  0x000800601e4d in _rtld_error () from /libexec/ld-elf.so.1
 #8  0x000800604ac2 in _rtld () from /libexec/ld-elf.so.1
 #9  0x000800601479 in .rtld_start () from /libexec/ld-elf.so.1
 #10 0x in ?? ()
 #11 0x in ?? ()
 #12 0x in ?? ()
 #13 0x in ?? ()
 #14 0x0001 in ?? ()
 #15 0x7fffeda0 in ?? ()
 #16 0x in ?? ()
 #17 0x7fffedf3 in ?? ()
 #18 0x7fffedfd in ?? ()
 #19 0x7fffee08 in ?? ()
 #20 0x7fffee17 in ?? ()
 #21 0x7fffee7d in ?? ()
 #22 0x7fffee91 in ?? ()
 #23 0x7fffee9d in ?? ()
 #24 0x7fffeeb2 in ?? ()
 #25 0x7fffeebd in ?? ()
 #26 0x7fffeece in ?? ()
 #27 0x7fffeedd in ?? ()
 
 Let me know if you need something else.

Unfortunately it looks like -g wasn't used during the build.

Best regards,
--Edwin
___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net


Re: [Clamav-devel] Tests failing on FreeBSD 6.x

2010-03-04 Thread Török Edwin
On 03/04/2010 04:07 PM, Renato Botelho wrote:
 2010/3/4 Török Edwin edwinto...@gmail.com:
 On 03/04/2010 03:12 PM, Renato Botelho wrote:
 I got a real 6.4 amd64 machine, and i reproduced the problem,
 here is the data i collected after build with -g:
 Did you set CXXFLAGS to -g? Setting CFLAGS has no effect on libclamav/c++

 testegw# gdb ./llvmunittest_ADT
 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain 
 conditions.
 Type show copying to see the conditions.
 There is absolutely no warranty for GDB.  Type show warranty for details.
 This GDB was configured as amd64-marcel-freebsd...
 (gdb) run
 Starting program:
 /home/garga/clamav-devel/work/clamav-devel-20100303/libclamav/c++/llvmunittest_ADT
 [New LWP 100047]
 [New Thread 0x60f000 (LWP 100047)]
 [New LWP 100047]

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to LWP 100047]
 0x00080073931d in _pthread_mutex_trylock () from /usr/lib/libthr.so.2
 (gdb) bt
 #0  0x00080073931d in _pthread_mutex_trylock () from 
 /usr/lib/libthr.so.2
 #1  0x000800739686 in pthread_mutex_lock () from /usr/lib/libthr.so.2
 #2  0x000800b740af in __register_frame_info_bases (begin=Variable
 begin is not available.
 ) at gthr-posix.h:611
 #3  0x000800b6c191 in frame_dummy () from 
 /usr/local/lib/gcc42/libgcc_s.so.1
 #4  0x in ?? ()
 #5  0x000800b6bf01 in _init () from /usr/local/lib/gcc42/libgcc_s.so.1
 #6  0x7fffeaf0 in ?? ()
 #7  0x000800601e4d in _rtld_error () from /libexec/ld-elf.so.1
 #8  0x000800604ac2 in _rtld () from /libexec/ld-elf.so.1
 #9  0x000800601479 in .rtld_start () from /libexec/ld-elf.so.1
 #10 0x in ?? ()
 #11 0x in ?? ()
 #12 0x in ?? ()
 #13 0x in ?? ()
 #14 0x0001 in ?? ()
 #15 0x7fffeda0 in ?? ()
 #16 0x in ?? ()
 #17 0x7fffedf3 in ?? ()
 #18 0x7fffedfd in ?? ()
 #19 0x7fffee08 in ?? ()
 #20 0x7fffee17 in ?? ()
 #21 0x7fffee7d in ?? ()
 #22 0x7fffee91 in ?? ()
 #23 0x7fffee9d in ?? ()
 #24 0x7fffeeb2 in ?? ()
 #25 0x7fffeebd in ?? ()
 #26 0x7fffeece in ?? ()
 #27 0x7fffeedd in ?? ()

 Let me know if you need something else.
 Unfortunately it looks like -g wasn't used during the build.
 
 Added, as you can see here:
 
 g++42 -DHAVE_CONFIG_H -I.  -I./llvm/include -I./llvm/include
 -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -D_DEBUG -D_GNU_SOURCE
 -I./llvm/utils/unittest/googletest/include -g -I/usr/local/include
 -Woverloaded-virtual -pedantic -Wno-long-long -Wall -W
 -Wno-unused-parameter -Wwrite-strings -Wno-missing-field-initializers
 -Wno-variadic-macros -fno-exceptions -O2 -fno-strict-aliasing -pipe -g
 -Wl,-rpath=/usr/local/lib/gcc42 -c -o

Yeah but its still using -O2, try removing -O2 too.

___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net


Re: [Clamav-devel] Tests failing on FreeBSD 6.x

2010-03-04 Thread Renato Botelho
2010/3/4 Török Edwin edwinto...@gmail.com:
 On 03/04/2010 04:07 PM, Renato Botelho wrote:
 2010/3/4 Török Edwin edwinto...@gmail.com:
 On 03/04/2010 03:12 PM, Renato Botelho wrote:
 I got a real 6.4 amd64 machine, and i reproduced the problem,
 here is the data i collected after build with -g:
 Did you set CXXFLAGS to -g? Setting CFLAGS has no effect on libclamav/c++

 testegw# gdb ./llvmunittest_ADT
 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you 
 are
 welcome to change it and/or distribute copies of it under certain 
 conditions.
 Type show copying to see the conditions.
 There is absolutely no warranty for GDB.  Type show warranty for details.
 This GDB was configured as amd64-marcel-freebsd...
 (gdb) run
 Starting program:
 /home/garga/clamav-devel/work/clamav-devel-20100303/libclamav/c++/llvmunittest_ADT
 [New LWP 100047]
 [New Thread 0x60f000 (LWP 100047)]
 [New LWP 100047]

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to LWP 100047]
 0x00080073931d in _pthread_mutex_trylock () from /usr/lib/libthr.so.2
 (gdb) bt
 #0  0x00080073931d in _pthread_mutex_trylock () from 
 /usr/lib/libthr.so.2
 #1  0x000800739686 in pthread_mutex_lock () from /usr/lib/libthr.so.2
 #2  0x000800b740af in __register_frame_info_bases (begin=Variable
 begin is not available.
 ) at gthr-posix.h:611
 #3  0x000800b6c191 in frame_dummy () from 
 /usr/local/lib/gcc42/libgcc_s.so.1
 #4  0x in ?? ()
 #5  0x000800b6bf01 in _init () from /usr/local/lib/gcc42/libgcc_s.so.1
 #6  0x7fffeaf0 in ?? ()
 #7  0x000800601e4d in _rtld_error () from /libexec/ld-elf.so.1
 #8  0x000800604ac2 in _rtld () from /libexec/ld-elf.so.1
 #9  0x000800601479 in .rtld_start () from /libexec/ld-elf.so.1
 #10 0x in ?? ()
 #11 0x in ?? ()
 #12 0x in ?? ()
 #13 0x in ?? ()
 #14 0x0001 in ?? ()
 #15 0x7fffeda0 in ?? ()
 #16 0x in ?? ()
 #17 0x7fffedf3 in ?? ()
 #18 0x7fffedfd in ?? ()
 #19 0x7fffee08 in ?? ()
 #20 0x7fffee17 in ?? ()
 #21 0x7fffee7d in ?? ()
 #22 0x7fffee91 in ?? ()
 #23 0x7fffee9d in ?? ()
 #24 0x7fffeeb2 in ?? ()
 #25 0x7fffeebd in ?? ()
 #26 0x7fffeece in ?? ()
 #27 0x7fffeedd in ?? ()

 Let me know if you need something else.
 Unfortunately it looks like -g wasn't used during the build.

 Added, as you can see here:

 g++42 -DHAVE_CONFIG_H -I.  -I./llvm/include -I./llvm/include
 -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -D_DEBUG -D_GNU_SOURCE
 -I./llvm/utils/unittest/googletest/include -g -I/usr/local/include
 -Woverloaded-virtual -pedantic -Wno-long-long -Wall -W
 -Wno-unused-parameter -Wwrite-strings -Wno-missing-field-initializers
 -Wno-variadic-macros -fno-exceptions -O2 -fno-strict-aliasing -pipe -g
 -Wl,-rpath=/usr/local/lib/gcc42 -c -o

 Yeah but its still using -O2, try removing -O2 too.

Without -O2, results changed

testegw# gdb ./llvmunittest_ADT
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd...
(gdb) run
Starting program:
/home/garga/clamav-devel/work/clamav-devel-20100303/libclamav/c++/llvmunittest_ADT
[New LWP 100049]
[New Thread 0x5dd000 (LWP 100049)]
[New LWP 100049]

Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 100049]
0x0008006f531d in _pthread_mutex_trylock () from /usr/lib/libthr.so.2
(gdb) bt
#0  0x0008006f531d in _pthread_mutex_trylock () from /usr/lib/libthr.so.2
#1  0x0008006f5686 in pthread_mutex_lock () from /usr/lib/libthr.so.2
#2  0x000800b300af in __register_frame_info_bases (begin=Variable
begin is not available.
) at gthr-posix.h:611
#3  0x000800b28191 in frame_dummy () from /usr/local/lib/gcc42/libgcc_s.so.1
#4  0x in ?? ()
#5  0x000800b27f01 in _init () from /usr/local/lib/gcc42/libgcc_s.so.1
#6  0x7fffeaf0 in ?? ()
#7  0x0008005bde4d in _rtld_error () from /libexec/ld-elf.so.1
#8  0x0008005c0ac2 in _rtld () from /libexec/ld-elf.so.1
#9  0x0008005bd479 in .rtld_start () from /libexec/ld-elf.so.1
#10 0x in ?? ()
#11 0x in ?? ()
#12 0x in ?? ()
#13 0x in ?? ()
#14 0x0001 in ?? ()
#15 0x in ?? ()
#16 0x7fffedf3 in ?? ()
#17 0x7fffedfd in ?? ()
#18 0x7fffee08 in ?? ()
#19 0x7fffee17 in ?? ()
#20 0x7fffee7d in ?? ()
#21 0x7fffee91 in ?? ()
#22 0x7fffee9d in ?? ()
#23 0x7fffeeb2 

Re: [Clamav-devel] Tests failing on FreeBSD 6.x

2010-03-04 Thread Török Edwin
On 03/04/2010 06:02 PM, Renato Botelho wrote:
 
 Without -O2, results changed
 
 #10 0x in ?? ()
 #11 0x in ?? ()
 #12 0x in ?? ()
 #13 0x in ?? ()
 #14 0x0001 in ?? ()
 #15 0x in ?? ()
 #16 0x7fffedf3 in ?? ()
 #17 0x7fffedfd in ?? ()
 #18 0x7fffee08 in ?? ()

Sorry that still doesn't tell me what the bug is.
Can you show me config.log (from libclamav/c++), maybe its linking to a
wrong library.

Could you also post a strace output of the program? (so we see what it
does prior to crashing)

Also try doing this:
(gdb) breakpoint main
(gdb) run
(gdb) next
(gdb) next
(gdb) quit

Best regards,
--Edwin
___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net


Re: [Clamav-devel] Tests failing on FreeBSD 6.x

2010-03-04 Thread Renato Botelho
2010/3/4 Török Edwin edwinto...@gmail.com:
 On 03/04/2010 06:02 PM, Renato Botelho wrote:

 Without -O2, results changed

 #10 0x in ?? ()
 #11 0x in ?? ()
 #12 0x in ?? ()
 #13 0x in ?? ()
 #14 0x0001 in ?? ()
 #15 0x in ?? ()
 #16 0x7fffedf3 in ?? ()
 #17 0x7fffedfd in ?? ()
 #18 0x7fffee08 in ?? ()

 Sorry that still doesn't tell me what the bug is.
 Can you show me config.log (from libclamav/c++), maybe its linking to a
 wrong library.

Attached

 Could you also post a strace output of the program? (so we see what it
 does prior to crashing)

Sorry, we don't have strace for freebsd amd64, just for i386

 Also try doing this:
 (gdb) breakpoint main
 (gdb) run
 (gdb) next
 (gdb) next
 (gdb) quit

It seems to segfault before main.

testegw# gdb ./llvmunittest_ADT
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd...
(gdb) break main
Breakpoint 1 at 0x462c39: file
llvm/utils/unittest/UnitTestMain/TestMain.cpp, line 13.
(gdb) run
Starting program:
/home/garga/clamav-devel/work/clamav-devel-20100303/libclamav/c++/llvmunittest_ADT
[New LWP 100101]
[New Thread 0x5dd000 (LWP 100101)]
[New LWP 100101]

Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 100101]
0x0008006f531d in _pthread_mutex_trylock () from /usr/lib/libthr.so.2
(gdb) next
Single stepping until exit from function _pthread_mutex_trylock,
which has no line number information.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) next
The program is not being run.
(gdb) quit
testegw#

I'm thinking this problem could be related with thread library. I'll
try to link it with libthr instead of libpthread and see what happens.

-- 
Renato Botelho


config.log
Description: Binary data
___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

Re: [Clamav-devel] Tests failing on FreeBSD 6.x

2010-03-04 Thread Török Edwin
On 03/04/2010 07:01 PM, Renato Botelho wrote:
 2010/3/4 Török Edwin edwinto...@gmail.com:
 On 03/04/2010 06:02 PM, Renato Botelho wrote:
 Without -O2, results changed

 #10 0x in ?? ()
 #11 0x in ?? ()
 #12 0x in ?? ()
 #13 0x in ?? ()
 #14 0x0001 in ?? ()
 #15 0x in ?? ()
 #16 0x7fffedf3 in ?? ()
 #17 0x7fffedfd in ?? ()
 #18 0x7fffee08 in ?? ()
 Sorry that still doesn't tell me what the bug is.
 Can you show me config.log (from libclamav/c++), maybe its linking to a
 wrong library.
 
 Attached
 
 Could you also post a strace output of the program? (so we see what it
 does prior to crashing)
 
 Sorry, we don't have strace for freebsd amd64, just for i386
 
 Also try doing this:
 (gdb) breakpoint main
 (gdb) run
 (gdb) next
 (gdb) next
 (gdb) quit
 
 It seems to segfault before main.
 
 testegw# gdb ./llvmunittest_ADT
 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain conditions.
 Type show copying to see the conditions.
 There is absolutely no warranty for GDB.  Type show warranty for details.
 This GDB was configured as amd64-marcel-freebsd...
 (gdb) break main
 Breakpoint 1 at 0x462c39: file
 llvm/utils/unittest/UnitTestMain/TestMain.cpp, line 13.
 (gdb) run
 Starting program:
 /home/garga/clamav-devel/work/clamav-devel-20100303/libclamav/c++/llvmunittest_ADT
 [New LWP 100101]
 [New Thread 0x5dd000 (LWP 100101)]
 [New LWP 100101]
 
 Program received signal SIGSEGV, Segmentation fault.
 [Switching to LWP 100101]
 0x0008006f531d in _pthread_mutex_trylock () from /usr/lib/libthr.so.2
 (gdb) next
 Single stepping until exit from function _pthread_mutex_trylock,
 which has no line number information.
 
 Program terminated with signal SIGSEGV, Segmentation fault.
 The program no longer exists.
 (gdb) next
 The program is not being run.
 (gdb) quit
 testegw#
 
 I'm thinking this problem could be related with thread library. I'll
 try to link it with libthr instead of libpthread and see what happens.
 

It already links with lthr, maybe try libpthread then?
LDFLAGS=' -L/usr/local/lib  -lthr -Wl,-rpath=/usr/local/lib/gcc42'

Best regards,
--Edwin
___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net


Re: [Clamav-devel] Tests failing on FreeBSD 6.x

2010-03-04 Thread Renato Botelho
2010/3/4 Török Edwin edwinto...@gmail.com:
 On 03/04/2010 07:01 PM, Renato Botelho wrote:
 2010/3/4 Török Edwin edwinto...@gmail.com:
 On 03/04/2010 06:02 PM, Renato Botelho wrote:
 Without -O2, results changed

 #10 0x in ?? ()
 #11 0x in ?? ()
 #12 0x in ?? ()
 #13 0x in ?? ()
 #14 0x0001 in ?? ()
 #15 0x in ?? ()
 #16 0x7fffedf3 in ?? ()
 #17 0x7fffedfd in ?? ()
 #18 0x7fffee08 in ?? ()
 Sorry that still doesn't tell me what the bug is.
 Can you show me config.log (from libclamav/c++), maybe its linking to a
 wrong library.

 Attached

 Could you also post a strace output of the program? (so we see what it
 does prior to crashing)

 Sorry, we don't have strace for freebsd amd64, just for i386

 Also try doing this:
 (gdb) breakpoint main
 (gdb) run
 (gdb) next
 (gdb) next
 (gdb) quit

 It seems to segfault before main.

 testegw# gdb ./llvmunittest_ADT
 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain conditions.
 Type show copying to see the conditions.
 There is absolutely no warranty for GDB.  Type show warranty for details.
 This GDB was configured as amd64-marcel-freebsd...
 (gdb) break main
 Breakpoint 1 at 0x462c39: file
 llvm/utils/unittest/UnitTestMain/TestMain.cpp, line 13.
 (gdb) run
 Starting program:
 /home/garga/clamav-devel/work/clamav-devel-20100303/libclamav/c++/llvmunittest_ADT
 [New LWP 100101]
 [New Thread 0x5dd000 (LWP 100101)]
 [New LWP 100101]

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to LWP 100101]
 0x0008006f531d in _pthread_mutex_trylock () from /usr/lib/libthr.so.2
 (gdb) next
 Single stepping until exit from function _pthread_mutex_trylock,
 which has no line number information.

 Program terminated with signal SIGSEGV, Segmentation fault.
 The program no longer exists.
 (gdb) next
 The program is not being run.
 (gdb) quit
 testegw#

 I'm thinking this problem could be related with thread library. I'll
 try to link it with libthr instead of libpthread and see what happens.


 It already links with lthr, maybe try libpthread then?
 LDFLAGS=' -L/usr/local/lib  -lthr -Wl,-rpath=/usr/local/lib/gcc42'

 Best regards,
 --Edwin
 ___
 http://lurker.clamav.net/list/clamav-devel.html
 Please submit your patches to our Bugzilla: http://bugs.clamav.net


So, something went wrong, unit test binary is linked with libpthread

testegw# ldd llvmunittest_ADT
llvmunittest_ADT:
libthr.so.2 = /usr/lib/libthr.so.2 (0x8006e7000)
libstdc++.so.6 = /usr/local/lib/gcc42/libstdc++.so.6 (0x8007fe000)
libm.so.4 = /lib/libm.so.4 (0x800a0a000)
libgcc_s.so.1 = /usr/local/lib/gcc42/libgcc_s.so.1 (0x800b26000)
libpthread.so.2 = /lib/libpthread.so.2 (0x800c33000)
libc.so.6 = /lib/libc.so.6 (0x800d5e000)
testegw#

-- 
Renato Botelho
___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net


Re: [Clamav-devel] Tests failing on FreeBSD 6.x

2010-03-04 Thread Renato Botelho
2010/3/4 Török Edwin edwinto...@gmail.com:
 On 03/04/2010 07:17 PM, Renato Botelho wrote:
 2010/3/4 Török Edwin edwinto...@gmail.com:
 On 03/04/2010 07:01 PM, Renato Botelho wrote:
 2010/3/4 Török Edwin edwinto...@gmail.com:
 On 03/04/2010 06:02 PM, Renato Botelho wrote:
 Without -O2, results changed

 #10 0x in ?? ()
 #11 0x in ?? ()
 #12 0x in ?? ()
 #13 0x in ?? ()
 #14 0x0001 in ?? ()
 #15 0x in ?? ()
 #16 0x7fffedf3 in ?? ()
 #17 0x7fffedfd in ?? ()
 #18 0x7fffee08 in ?? ()
 Sorry that still doesn't tell me what the bug is.
 Can you show me config.log (from libclamav/c++), maybe its linking to a
 wrong library.
 Attached

 Could you also post a strace output of the program? (so we see what it
 does prior to crashing)
 Sorry, we don't have strace for freebsd amd64, just for i386

 Also try doing this:
 (gdb) breakpoint main
 (gdb) run
 (gdb) next
 (gdb) next
 (gdb) quit
 It seems to segfault before main.

 testegw# gdb ./llvmunittest_ADT
 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you 
 are
 welcome to change it and/or distribute copies of it under certain 
 conditions.
 Type show copying to see the conditions.
 There is absolutely no warranty for GDB.  Type show warranty for details.
 This GDB was configured as amd64-marcel-freebsd...
 (gdb) break main
 Breakpoint 1 at 0x462c39: file
 llvm/utils/unittest/UnitTestMain/TestMain.cpp, line 13.
 (gdb) run
 Starting program:
 /home/garga/clamav-devel/work/clamav-devel-20100303/libclamav/c++/llvmunittest_ADT
 [New LWP 100101]
 [New Thread 0x5dd000 (LWP 100101)]
 [New LWP 100101]

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to LWP 100101]
 0x0008006f531d in _pthread_mutex_trylock () from /usr/lib/libthr.so.2
 (gdb) next
 Single stepping until exit from function _pthread_mutex_trylock,
 which has no line number information.

 Program terminated with signal SIGSEGV, Segmentation fault.
 The program no longer exists.
 (gdb) next
 The program is not being run.
 (gdb) quit
 testegw#

 I'm thinking this problem could be related with thread library. I'll
 try to link it with libthr instead of libpthread and see what happens.

 It already links with lthr, maybe try libpthread then?
 LDFLAGS=' -L/usr/local/lib  -lthr -Wl,-rpath=/usr/local/lib/gcc42'

 Best regards,
 --Edwin
 ___
 http://lurker.clamav.net/list/clamav-devel.html
 Please submit your patches to our Bugzilla: http://bugs.clamav.net


 So, something went wrong, unit test binary is linked with libpthread

 Can you show me the output of:
 rm llvmunittest_ADT
 make llvmunittest_ADT V=1



 testegw# ldd llvmunittest_ADT
 llvmunittest_ADT:
         libthr.so.2 = /usr/lib/libthr.so.2 (0x8006e7000)
         libstdc++.so.6 = /usr/local/lib/gcc42/libstdc++.so.6 (0x8007fe000)
         libm.so.4 = /lib/libm.so.4 (0x800a0a000)
         libgcc_s.so.1 = /usr/local/lib/gcc42/libgcc_s.so.1 (0x800b26000)
         libpthread.so.2 = /lib/libpthread.so.2 (0x800c33000)
         libc.so.6 = /lib/libc.so.6 (0x800d5e000)

 Ouch, how did the linker even allow that?!


Yeah, I think we found it:

/bin/sh ./libtool  --tag=CXX--mode=link g++42 -Woverloaded-virtual
-pedantic -Wno-long-long -Wall -W -Wno-unused-parameter
-Wwrite-strings -Wno-missing-field-initializers -Wno-variadic-macros
-fno-exceptions  -fno-strict-aliasing -pipe -g
-Wl,-rpath=/usr/local/lib/gcc42  -L/usr/local/lib  -lthr
-Wl,-rpath=/usr/local/lib/gcc42 -o llvmunittest_ADT
llvmunittest_ADT-APFloatTest.o  llvmunittest_ADT-APIntTest.o
llvmunittest_ADT-DenseMapTest.o  llvmunittest_ADT-DenseSetTest.o
llvmunittest_ADT-ImmutableSetTest.o
llvmunittest_ADT-SmallStringTest.o  llvmunittest_ADT-SmallVectorTest.o
 llvmunittest_ADT-SparseBitVectorTest.o
llvmunittest_ADT-StringMapTest.o  llvmunittest_ADT-StringRefTest.o
llvmunittest_ADT-TripleTest.o  llvmunittest_ADT-TwineTest.o
libgoogletest.la libllvmjit.la libllvmsupport.la libllvmsystem.la
libtool: link: g++42 -Woverloaded-virtual -pedantic -Wno-long-long
-Wall -W -Wno-unused-parameter -Wwrite-strings
-Wno-missing-field-initializers -Wno-variadic-macros -fno-exceptions
-fno-strict-aliasing -pipe -g -Wl,-rpath=/usr/local/lib/gcc42
-Wl,-rpath=/usr/local/lib/gcc42 -o llvmunittest_ADT
llvmunittest_ADT-APFloatTest.o llvmunittest_ADT-APIntTest.o
llvmunittest_ADT-DenseMapTest.o llvmunittest_ADT-DenseSetTest.o
llvmunittest_ADT-ImmutableSetTest.o llvmunittest_ADT-SmallStringTest.o
llvmunittest_ADT-SmallVectorTest.o
llvmunittest_ADT-SparseBitVectorTest.o
llvmunittest_ADT-StringMapTest.o llvmunittest_ADT-StringRefTest.o
llvmunittest_ADT-TripleTest.o llvmunittest_ADT-TwineTest.o
-L/usr/local/lib ./.libs/libgoogletest.a ./.libs/libllvmjit.a
./.libs/libllvmsupport.a ./.libs/libllvmsystem.a -lthr -pthread

-- 
Renato Botelho

Re: [Clamav-devel] Tests failing on FreeBSD 6.x

2010-03-04 Thread Török Edwin
On 03/04/2010 07:25 PM, Renato Botelho wrote:
 testegw# ldd llvmunittest_ADT
 llvmunittest_ADT:
 libthr.so.2 = /usr/lib/libthr.so.2 (0x8006e7000)
 libstdc++.so.6 = /usr/local/lib/gcc42/libstdc++.so.6 (0x8007fe000)
 libm.so.4 = /lib/libm.so.4 (0x800a0a000)
 libgcc_s.so.1 = /usr/local/lib/gcc42/libgcc_s.so.1 (0x800b26000)
 libpthread.so.2 = /lib/libpthread.so.2 (0x800c33000)
 libc.so.6 = /lib/libc.so.6 (0x800d5e000)
 Ouch, how did the linker even allow that?!
 
 
 Yeah, I think we found it:

Ok that comes from here libclamav/c++/Makefile.am:
libllvmsystem_la_LDFLAGS=-pthread

I thought -pthread is the appropriate thing to use (the OpenBSD manpage
says so at least), guess I should pass @THREAD_LIBS@ from ClamAV's main
configure to the one in libclamav/c++.


Best regards,
--Edwin
___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net


Re: [Clamav-devel] Tests failing on FreeBSD 6.x

2010-03-04 Thread Török Edwin
On 03/04/2010 08:51 PM, Renato Botelho wrote:
 2010/3/4 Török Edwin edwinto...@gmail.com:
 On 03/04/2010 08:44 PM, Renato Botelho wrote:
 2010/3/4 Török Edwin edwinto...@gmail.com:
 On 03/04/2010 08:37 PM, Renato Botelho wrote:
 2010/3/4 Török Edwin edwinto...@gmail.com:
 On 03/04/2010 08:29 PM, Renato Botelho wrote:
 2010/3/4 Török Edwin edwinto...@gmail.com:
 On 03/04/2010 08:23 PM, Renato Botelho wrote:
 2010/3/4 Török Edwin edwinto...@gmail.com:
 On 03/04/2010 08:16 PM, Renato Botelho wrote:
 No -pthread around unit_tests
 Please look in all .la files for pthread.
 No results
 last chance, grep the Makefiles :)
 Result of this command:

 find ./ -type f | xargs fgrep -i -- -pthread

 here:

 http://pastebin.com/MHuScqae

 testegw# find ./ -type f -iname \*.la | xargs fgrep pthread
 from clamav's source/build root, right?
 Yes.

 Ok it seems that this:
 -lthr
 -L/usr/local/lib -lcheck -R/usr/local/lib

 got expanded to this:
 -lthr usr/local/lib/libcheck.so -pthread -Wl,-rpath
 -Wl,/usr/local/lib

 Is there a /usr/local/lib/libcheck.la, and does it have anything about
 pthread in it?
 Bingo,

 # Linker flags that can not go in dependency_libs.
 inherited_linker_flags=' -pthread'

 But why is that like so? Isn't -lthr FreeBSD's threading library that
 you build the ports with?
 The default thread library on FreeBSD ports is -pthread, I forced
 clamav to build using -lthr because we had problems in the past
 with -pthread.
 For freebsd 4 and 5 configure sets THREAD_LIBS to -pthread -lc_r
 and for later ones to -lthr (unless you patched configure to use
 PTHREAD_LIBS?).
 
 Exactly
 
 If you patched the main configure to use PTHREAD_LIBS, then please patch
 libclamav/c++ too.
 
 Ok, i'll do (after patch you sent is it still necessary?)

Well it does the same as the main configure: use -lthr.
So if you patched the main configure to use PTHREAD_LIBS instead of
-lthr, you should do the same for libclamav/c++.

I don't know what our version should do:
 - official freebsd port uses -lthr for clamav (and so do we)
 - libcheck uses -pthread

I don't want to switch clamav to -pthread just because of libcheck,
if -lthr works better (for clamav).

FWIW on Debian there is no libcheck.la, there is just a libcheck.a, and
libcheck_pic.a.

Would it be possible to link to libcheck.a on FreeBSD? libclamav is
already linked with the proper threading libs...

Also I'm told latest FreeBSD only has 1 threading lib.
Which is it? -lthr or -lpthread? (or does -pthread imply -lthr there?).

 
 libcheck port doesn't have this forced, so, it used the default when
 it was built.

 I can try to build clamav using the default thread and see what
 happens.

 On 03/04/2010 08:46 PM, Renato Botelho wrote:
 I cannot remember when it was done, but there is a comment about
 it on ports Makefile

 # This port has a problem with -pthread,
 # force to use -lthr until it's not fixed.
 PTHREAD_LIBS=  -pthread

 I don't understand, the comment says force -lthr, but the Makefile does
 -pthread.
 
 I replaced it with -pthread right now to make a test, the official port
 uses -lthr

Ah ok.

 
 And why did it work so far? I don't think I changed anything wrt libcheck.
 good question

 Did you build the unit tests for 0.95?
 
 Nope, i'll try it too
 

Thanks.

Best regards,
--Edwin
___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net


[Clamav-devel] bugzilla message

2010-03-04 Thread Reini Urban

https://wwws.clamav.net/bugzilla/ shows a warning.

Please do not report any bug affecting software derived from ClamAV and 
distributed by a third party (e.g. ClamWin, clamav-win32, ClamXav) 
because we have no control over them. Contact their developers instead. 
Bugs in the CygWin based ports like ClamWin and clamav-win32 should be 
reported to Reini Urban


This is wrong.
1. Bugs in the cygwin port should be reported to cyg...@cygwin.com
2. There are no CygWin based ports like ClamWin and clamav-win32
--
Reini Urban
http://phpwiki.org/  http://murbreak.at/
___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net