# bro segfaults on startup **URL:** \ **Category:** Zeek\ **Created:** [January 10, 2006, 6:42pm UTC](https://community.zeek.org/t/bro-segfaults-on-startup/913 "2006-01-10T18:42:34Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Vern](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/vern/32/630_2.png) [@Vern](https://community.zeek.org/u/Vern)\ **Post date:** [January 10, 2006, 6:42pm UTC](https://community.zeek.org/t/bro-segfaults-on-startup/913/1 "2006-01-10T18:42:34Z")
> Which packet filter do you mean? I meant the libpcap. But: > Scott Campbell mentioned it may be a problem with the resolver library, > as others have had similar problems in the past. this is clearly the problem, given the traceback that terminates inside the resolver library: > (gdb) run -i eth0 mt http ftp scan > Starting program: /opt/bro-1.0/bin/bro -i eth0 mt http ftp scan > > Program received signal SIGSEGV, Segmentation fault. > 0x0000000000561ef5 in \_\_ns\_initparse () > (gdb) bt > #0 0x0000000000561ef5 in \_\_ns\_initparse () > Cannot access memory at address 0xffd2a510 This may be a longshot, but in the past folks have worked around resolver problems on Linux but linking to /usr/lib/libresolv.a directly. Worth giving a try. FWIW, we run without problems on Red Hat 2.4.21. But we're not running 64-bit native, which it looks like you are. (Our glibc is a slightly older, but I don't imagine that matters.) Scott, do you recall any other fixes?     Vern ---
**Author:** ![Scott\_Campbell](https://avatars.discourse-cdn.com/v4/letter/s/54ee81/32.png) [@Scott\_Campbell](https://community.zeek.org/u/Scott_Campbell)\ **Post date:** [January 10, 2006, 7:01pm UTC](https://community.zeek.org/t/bro-segfaults-on-startup/913/2 "2006-01-10T19:01:58Z")
Vern Paxson wrote: > > Which packet filter do you mean? > > I meant the libpcap. But: > > > Scott Campbell mentioned it may be a problem with the resolver library, > > as others have had similar problems in the past. > > this is clearly the problem, given the traceback that terminates inside > the resolver library: > > > (gdb) run -i eth0 mt http ftp scan > > Starting program: /opt/bro-1.0/bin/bro -i eth0 mt http ftp scan > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x0000000000561ef5 in \_\_ns\_initparse () > > (gdb) bt > > #0 0x0000000000561ef5 in \_\_ns\_initparse () > > Cannot access memory at address 0xffd2a510 > > This may be a longshot, but in the past folks have worked around resolver > problems on Linux but linking to /usr/lib/libresolv.a directly. Worth > giving a try. > > FWIW, we run without problems on Red Hat 2.4.21. But we're not running > 64-bit native, which it looks like you are. (Our glibc is a slightly older, > but I don't imagine that matters.) > > Scott, do you recall any other fixes? > >     Vern > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > Bro mailing list > bro@bro-ids.org > [mailman.icsi.berkeley.edu Mailing Lists](http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro) Unfortunately I suggested that our discussion get punted back to the list since I have no experience with the 64 bit libs on linux. I suspect that you may be correct about the linking. If that does not work you may want to explore forcing the issue of compiling & running in 32 bit mode. If this continues to be a problem, I can ask around here and see what other peoples suggestions are. scott ---
**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\ **Post date:** [January 10, 2006, 7:28pm UTC](https://community.zeek.org/t/bro-segfaults-on-startup/913/3 "2006-01-10T19:28:17Z")
Ah, 64 bit and resolver-problems, that rings a bell: I've seen core-dumps on a 64bit SUSE Linux which were caused by linking in the 32bit version of the resolver-library. However, I recall that there was a corresponding warning during compiling/linking (which was easy to miss though). David, do you see anything like this? Robin ---
**Author:** ![David\_Vasil1](https://avatars.discourse-cdn.com/v4/letter/d/6a8cbe/32.png) [@David\_Vasil1](https://community.zeek.org/u/David_Vasil1)\ **Post date:** [January 10, 2006, 7:53pm UTC](https://community.zeek.org/t/bro-segfaults-on-startup/913/4 "2006-01-10T19:53:46Z")
Robin Sommer wrote: > Ah, 64 bit and resolver-problems, that rings a bell: I've seen > core-dumps on a 64bit SUSE Linux which were caused by linking in the > 32bit version of the resolver-library. However, I recall that there > was a corresponding warning during compiling/linking (which was easy > to miss though). David, do you see anything like this? Yes, during the compile of bro the following message is seen: g++ -g -O2 -o bro dce\_rpc\_pac.o ncp\_pac.o smb\_pac.o main.o net\_util.o util.o parse.o scan.o re-parse.o re-scan.o rule-parse.o rule-scan.o Active.o Anon.o Attr.o BackDoor.o Base64.o BPF\_Program.o BroString.o CCL.o ChunkedIO.o CompHash.o Conn.o ConnCompressor.o DCE\_RPC.o DFA.o DNS.o DNS\_Mgr.o DbgBreakpoint.o DbgHelp.o DbgWatch.o Debug.o DebugCmds.o DebugLogger.o Desc.o Dict.o Discard.o EquivClass.o Event.o EventHandler.o EventRegistry.o Expr.o FTP.o File.o Finger.o Frag.o Frame.o Func.o Gnutella.o HTTP.o Hash.o ICMP.o ID.o Ident.o IntSet.o InterConn.o IOSource.o IRC.o List.o Logger.o Login.o MIME.o NCP.o NFA.o NFS.o NTP.o NVT.o Net.o NetVar.o NetbiosSSN.o Obj.o OSFinger.o PacketFilter.o PacketSort.o PersistenceSerializer.o PktSrc.o PolicyFile.o POP3.o Portmap.o PrefixTable.o PriorityQueue.o Queue.o RE.o RPC.o Reassem.o RemoteSerializer.o Rlogin.o RSH.o Rule.o RuleAction.o RuleCondition.o RuleMatcher.o ScriptAnaly.o SMB.o SmithWaterman.o SMTP.o SSH.o Scope.o SerializationFormat.o SerialObj.o Serializer.o Sessions.o StateAccess.o Stats.o SteppingStone.o Stmt.o TCP.o TCP\_Contents.o TCP\_Endpoint.o TCP\_Rewriter.o Telnet.o Timer.o Traverse.o TwoWise.o Type.o UDP.o Val.o Var.o XDR.o bsd-getopt-long.o cq.o md5.o patricia.o setsignal.o version.o strsep.o nb\_dns.o X509.o SSLCiphers.o SSLInterpreter.o SSLProxy.o SSLv2.o SSLv3.o SSLv3Automaton.o -Llibedit -ledit -L../aux/libpcap-0.7.2 -lpcap -lresolv -lz /usr/lib/libresolv.a -lssl -lcrypto /usr/lib/libresolv.a -ltermcap -lm /usr/bin/ld: warning: i386 architecture of input file `/usr/lib/libresolv.a(ns\_parse.o)' is incompatible with i386:x86-64 output I assume that is the error we are looking for. Unfortunately, it seems that removing the references to /usr/lib/libresolv.a in each of the Makefiles causes ns\_initparse to go undefined and make fails: gcc -DHAVE\_CONFIG\_H -I. -I. -I../.. -g -O2 -I/include -c `test -f nb_dns.c || echo './'`nb\_dns.c gcc -g -O2 -I/include -o hf hf.o setsignal.o version.o nb\_dns.o -L../../aux/libpcap-0.7.2 -lpcap -lresolv -lz -lssl -lcrypto -ltermcap nb\_dns.o(.text+0x671): In function `nb\_dns\_activity': /raid/work/bro-1.0/aux/hf/nb\_dns.c:476: undefined reference to `\_\_ns\_initparse' nb\_dns.o(.text+0x7ae):/raid/work/bro-1.0/aux/hf/nb\_dns.c:519: undefined reference to `\_ns\_flagdata' nb\_dns.o(.text+0x7ca):/raid/work/bro-1.0/aux/hf/nb\_dns.c:519: undefined reference to `\_ns\_flagdata' nb\_dns.o(.text+0x93c):/raid/work/bro-1.0/aux/hf/nb\_dns.c:561: undefined reference to `\_\_ns\_parserr' collect2: ld returned 1 exit status make[4]: \*\*\* [hf] Error 1 make[4]: Leaving directory `/raid/work/bro-1.0/aux/hf' make[3]: \*\*\* [all-recursive] Error 1 make[3]: Leaving directory `/raid/work/bro-1.0/aux' make[2]: \*\*\* [all] Error 2 make[2]: Leaving directory `/raid/work/bro-1.0/aux' make[1]: \*\*\* [all-recursive] Error 1 make[1]: Leaving directory `/raid/work/bro-1.0' make: \*\*\* [all] Error 2 I'll look into it more, figured you might like an update though. ---
**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\ **Post date:** [January 11, 2006, 4:04am UTC](https://community.zeek.org/t/bro-segfaults-on-startup/913/5 "2006-01-11T04:04:28Z")
That sounds indeed familiar. On the SUSE system, this hack solved the problem: (1) Patching configure.in: --- configure.in~ 2005-12-22 01:12:21.000000000 +0100 +++ configure.in 2005-12-22 01:12:21.000000000 +0100 @@ -241,7 +241,7 @@ dnl Specifying a specific resolver library seems to work/be necessary dnl on all OSs, but Darwin needs -lresolv instead of /usr/lib/libresolv.a dnl We define the default here and overwrite below. --ck -bro\_libresolv="/usr/lib/libresolv.a" +bro\_libresolv="/usr/lib64/libresolv.a" case "$target\_os" in (2) Running ./autogen.sh (3) LDFLAGS=-L/usr/lib64/termcap/ ./configure Robin ---
**Author:** ![David\_Vasil1](https://avatars.discourse-cdn.com/v4/letter/d/6a8cbe/32.png) [@David\_Vasil1](https://community.zeek.org/u/David_Vasil1)\ **Post date:** [January 11, 2006, 1:52pm UTC](https://community.zeek.org/t/bro-segfaults-on-startup/913/6 "2006-01-11T13:52:24Z")
Robin Sommer wrote: ---
**Author:** ![system](https://canada1.discourse-cdn.com/flex011/uploads/zeek/original/1X/f09d732bc2cc7c7cc7e35db67cf4e1d5233ce7a7.png) [@system](https://community.zeek.org/u/system)\ **Post date:** [May 6, 2022, 3:37pm UTC](https://community.zeek.org/t/bro-segfaults-on-startup/913/7 "2022-05-06T15:37:46Z")
Closed on May 6, 2022, 3:37pm UTC