If I use the default configuration it segfaults
As is always the case when reporting crashes, it is highly helpful if you
can please include a debugger traceback showing the problem. Otherwise
we're pretty much stuck with trying to fix it if it doesn't happen to
reproduce in our development environments.
Vern
I tried compiling with CFLAGS='-g' and CXXFLAGS='-g' and while it
included the -g in all the compile lines when it went by I still don't
seem to get additional info in the gdb backtrace. However during
compile I get about 30 or 40 warnings per file about mismatched sizes
for ints. So I'm kinda guessing it might be related to 64bit
compatability if it's not just something i am doing wrong. Whatever
the case gdb seems unable to give me any more info then that one line
of output. If anyone has a better suggestion on how to get debugger
traceback with more info I will be happy to post that output.
Thanks,
Charles comstock
Linux bb4.arl.wustl.edu 2.6.9-1.667smp #1 SMP Tue Nov 2 15:09:11 EST
2004 x86_64 x86_64 x86_64 GNU/Linux
root@bb4:~/bro-0.9a9 [15:42:59]#] src/bro -i eth3 bb4.arl.wustl.edu.bro
Segmentation fault
root@bb4:~/bro-0.9a9 [15:43:14]#] gdb src/bro
GNU gdb Red Hat Linux (6.1post-1.20040607.43rh)
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 "x86_64-redhat-linux-gnu"...Using host
libthread_db library "/lib64/tls/libthread_db.so.1".
(gdb) run -i eth3 bb4.arl.wustl.edu.bro
Starting program: /root/bro-0.9a9/src/bro -i eth3 bb4.arl.wustl.edu.bro
Program received signal SIGSEGV, Segmentation fault.
0x0000000000528da1 in __ns_initparse ()
I tried compiling with CFLAGS='-g' and CXXFLAGS='-g' and while it
included the -g in all the compile lines when it went by I still don't
seem to get additional info in the gdb backtrace. However during
compile I get about 30 or 40 warnings per file about mismatched sizes
for ints.
Could you post a few examples of those (or alternatively, send me the
full output off-line)?
So I'm kinda guessing it might be related to 64bit
compatability if it's not just something i am doing wrong. Whatever
the case gdb seems unable to give me any more info then that one line
of output. If anyone has a better suggestion on how to get debugger
traceback with more info I will be happy to post that output.
What happens when you type "bt" at the gdb prompt, when gdb shows you
the message you're posting below?
Thanks,
Charles comstockLinux bb4.arl.wustl.edu 2.6.9-1.667smp #1 SMP Tue Nov 2 15:09:11 EST
2004 x86_64 x86_64 x86_64 GNU/Linux
root@bb4:~/bro-0.9a9 [15:42:59]#] src/bro -i eth3 bb4.arl.wustl.edu.bro
Segmentation fault
root@bb4:~/bro-0.9a9 [15:43:14]#] gdb src/bro
GNU gdb Red Hat Linux (6.1post-1.20040607.43rh)
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 "x86_64-redhat-linux-gnu"...Using host
libthread_db library "/lib64/tls/libthread_db.so.1".(gdb) run -i eth3 bb4.arl.wustl.edu.bro
Starting program: /root/bro-0.9a9/src/bro -i eth3 bb4.arl.wustl.edu.broProgram received signal SIGSEGV, Segmentation fault.
0x0000000000528da1 in __ns_initparse ()
Cheers,
Christian.
> I tried compiling with CFLAGS='-g' and CXXFLAGS='-g' and while it
> included the -g in all the compile lines when it went by I still don't
> seem to get additional info in the gdb backtrace. However during
> compile I get about 30 or 40 warnings per file about mismatched sizes
> for ints.Could you post a few examples of those (or alternatively, send me the
full output off-line)?
Here is some example output, it's like this for alot of files though.
g++ -DHAVE_CONFIG_H -I. -I. -I.. -I. -I../src -I. -I.. -Ilibedit
-I../linux-include -I../aux/libpcap-0.7.2 -O -g -g -c -o main.o
`test -f main.cc || echo './'`main.cc
In file included from DNS_Mgr.h:28,
from main.cc:42:
EventHandler.h: In member function `void
EventHandler::SourceIDList::insert(SourceID)':
EventHandler.h:53: warning: cast to pointer from integer of different size
EventHandler.h: In member function `void
EventHandler::SourceIDList::sortedinsert(SourceID, int (*)(const
void*, const void*))':
EventHandler.h:53: warning: cast to pointer from integer of different size
EventHandler.h: In member function `void
EventHandler::SourceIDList::append(SourceID)':
EventHandler.h:53: warning: cast to pointer from integer of different size
EventHandler.h: In member function `SourceID
EventHandler::SourceIDList::remove(SourceID)':
EventHandler.h:53: warning: cast to pointer from integer of different size
EventHandler.h:53: warning: cast from pointer to integer of different size
EventHandler.h: In member function `SourceID
EventHandler::SourceIDList::remove_nth(int)':
EventHandler.h:53: warning: cast from pointer to integer of different size
EventHandler.h: In member function `SourceID EventHandler::SourceIDList::get()':
EventHandler.h:53: warning: cast from pointer to integer of different size
EventHandler.h: In member function `SourceID
EventHandler::SourceIDList::last()':
EventHandler.h:53: warning: cast from pointer to integer of different size
EventHandler.h: In member function `SourceID
EventHandler::SourceIDList::replace(int, SourceID)':
EventHandler.h:53: warning: cast to pointer from integer of different size
EventHandler.h:53: warning: cast from pointer to integer of different size
EventHandler.h: In member function `SourceID
EventHandler::SourceIDList::is_member(SourceID) const':
EventHandler.h:53: warning: cast to pointer from integer of different size
EventHandler.h:53: warning: cast from pointer to integer of different size
EventHandler.h: In member function `int
EventHandler::SourceIDList::member_pos(SourceID) const':
EventHandler.h:53: warning: cast to pointer from integer of different size
EventHandler.h: In member function `SourceID
EventHandler::SourceIDList::operator(int) const':
EventHandler.h:53: warning: cast from pointer to integer of different size
> So I'm kinda guessing it might be related to 64bit
> compatability if it's not just something i am doing wrong. Whatever
> the case gdb seems unable to give me any more info then that one line
> of output. If anyone has a better suggestion on how to get debugger
> traceback with more info I will be happy to post that output.What happens when you type "bt" at the gdb prompt, when gdb shows you
the message you're posting below?
When I print a bt I get the same line:
0x0000000000528da1 in __ns_initparse ()
I think by default gdb displays bt when the program exits abnormally.
Is there a different flag then -g I should be feeding the compiler in
order to get more backtrace info?
Thanks,
Charles Comstock
Here is some example output, it's like this for alot of files though.
g++ -DHAVE_CONFIG_H -I. -I. -I.. -I. -I../src -I. -I.. -Ilibedit -I../linux-include -I../aux/libpcap-0.7.2 -O -g -g -c -o main.o
`test -f main.cc || echo './'`main.cc
In file included from DNS_Mgr.h:28,
from main.cc:42:
EventHandler.h: In member function `void
EventHandler::SourceIDList::insert(SourceID)':
EventHandler.h:53: warning: cast to pointer from integer of different size
EventHandler.h: In member function `void
EventHandler::SourceIDList::sortedinsert(SourceID, int (*)(const
void*, const void*))':
EventHandler.h:53: warning: cast to pointer from integer of different size
EventHandler.h: In member function `void
EventHandler::SourceIDList::append(SourceID)':
EventHandler.h:53: warning: cast to pointer from integer of different size
EventHandler.h: In member function `SourceID
Unless I'm missing something, this does look broken. Here are the snippets from the post-processed translation unit
of EventHandler.h:
typedef void* ent;
typedef uint32 SourceID;
struct SourceIDList : BaseList { void insert(SourceID a) { BaseList::insert(ent(a)); }
Needless to say, on a 64 bit architecture casting a 32bit into to a 64bit value is a mistake.
I'm assuming this code was written before templates became practical in a
performance sensitive environment. Perhaps its time for an upgrade?
.m
>
>
>
>Here is some example output, it's like this for alot of files though.
>
>g++ -DHAVE_CONFIG_H -I. -I. -I.. -I. -I../src -I. -I.. -Ilibedit
>-I../linux-include -I../aux/libpcap-0.7.2 -O -g -g -c -o main.o
>`test -f main.cc || echo './'`main.cc
>In file included from DNS_Mgr.h:28,
> from main.cc:42:
>EventHandler.h: In member function `void
>EventHandler::SourceIDList::insert(SourceID)':
>EventHandler.h:53: warning: cast to pointer from integer of different size
>EventHandler.h: In member function `void
>EventHandler::SourceIDList::sortedinsert(SourceID, int (*)(const
>void*, const void*))':
>EventHandler.h:53: warning: cast to pointer from integer of different size
>EventHandler.h: In member function `void
>EventHandler::SourceIDList::append(SourceID)':
>EventHandler.h:53: warning: cast to pointer from integer of different size
>EventHandler.h: In member function `SourceID
Thanks for the output, Charles (and Martin Arlitt, who sent me output
off-line).
Unless I'm missing something, this does look broken. Here are the
snippets from the post-processed translation unit
of EventHandler.h:typedef void* ent;
typedef uint32 SourceID;
struct SourceIDList : BaseList { void insert(SourceID a) {
BaseList::insert(ent(a)); }Needless to say, on a 64 bit architecture casting a 32bit into to a
64bit value is a mistake.
Yeah. The problem is the hard-coded difference between lists of
instances of types (cf. List macros) and lists of pointers to instances
(cf. PList macros). Here the former is used, which breaks on 64-bit
architectures. Luckily List is used very rarely, I can only find
declare(List,int) in CCL.h
declare(List, SourceID) in EventHandler.h
I presume it's somewhat tedious to change the code from List to PList
since it'll involve rethinking allocation/deallocation of container
elements, but it's the only solution I can think of. Mhm. Unless we
throw out the macro containers and switch to STL ones. What's your take
on this Vern?
I'm assuming this code was written before templates became practical in a
performance sensitive environment. Perhaps its time for an upgrade?
Fwiw, I'd like to see the self-implemented containers go as well.
Cheers,
Christian.
Actually, wouldn't it work if we changed
typedef uint32 SourceID
to
typedef uint64 SourceID
in util.h on architectures where pointers aren't 32bit? I'd still prefer
to get rid of the macro containers but this might be a quicker fix.
Well, except for any spots in the code that rely on SourceIDs being 32-
bit (serialization maybe?), of course, and for the configure kung-fu
needed.
Cheers,
Christian.
elements, but it's the only solution I can think of. Mhm. Unless we
throw out the macro containers and switch to STL ones.
For the few occurenes of List this should be fine. Not sure if it
makes sense to replace all macro containers. While I'd like to see
that, too, it's appears to be a lot of work and may influence
performance significantly (either positively or negatively, not
sure).
typedef uint64 SourceID
Should be fine. SourceIDs are not serialized and they are rarely
stored somewhere, i.e. they are not consuming a significant amount
of memory.
configure kung-fu
TransientID::ID already depends on being 64-bit and uses a long-long
for its tyoe (plus a compile-time check whether long-long are indeed
64-bit). I remember that there was a problem with a nicer "kung-fu"
but I don't recall what is was...
Robin
Nice, that'll help. We'll also need a check for the size of pointers on
the system we're building for, but that shouldn't be too hard.
Cheers,
Christian.
Hi,
I'm attaching a patch for the 64-bit people out there to try. Note that
I could only do build tests (using FC3 on an Opteron on SF's compile
farm, *so* slow!) but not do any operational tests. Let us know if it
works -- feedback appreciated!
Cheers,
Christian.
bro-64bit.diff (6.17 KB)