Re: ipf 4.1.32RC4 crashes Solaris9
Joseph Tam <[email protected]>
| Newsgroups | gmane.comp.security.firewalls.ipfilter |
|---|---|
| Message-ID | <30915_1239529898_49E1B9A9_30915_5227_1_Pine.GSO.4.64.0904120244400.27394@mnc.zngu.hop.pn> |
On Thu, 9 Apr 2009, Darren Reed wrote: > | I spoke too soon when I reported this being stable for Solaris8/9. > | It still crashes my Sol9 loaded DNS server. The symptoms are the same: > | it is stable just as long as you don't filter by UDP ports, but as soon > | as you add UDP port filter rules, it will crash after a while. > | > | I ran ACT on the core dump, and I've included the relevant portion of the > | output. Trap 0x31 is some sort of data access MMU miss in fr_derefrule(). > | What could cause that? > > A bad pointer... something similar has been seen on FreeBSD, so it is kind > of comforting to see this... > See: > http://sourceforge.net/tracker/?func=detail&aid=2706212&group_id=169098&atid > =849053 > ... > | 20fc07a panic[cpu1]/thread=30003367340: 20fc07a BAD TRAP: type=31 > rp=2a100370720 addr=30000c59b2c mmu_fsr=0 > | 20fc07a 20fc07a dnscache: 20fc07a trap type = 0x31 > | 20fc07a addr=0x30000c59b2c > | 20fc07a pid=363, pc=0x118b8a8, sp=0x2a10036ffc1, tstate=0x80001600, > | context=0x8a4 > > If you can go into /var/crash/machine and run "adb -k *.#", what > does the output of "0x118b8a8/i" say? I was afraid you were going to ask that. I deleted those core dumps. Let's see, it's now 2am on Easter Sunday -- it shouldn't be too disruptive to cause another crash: add UDP port rules ... swap in firewall rules ... resolve apache log file to generate DNS traffic, bingo! core dump. The PC had the same value, so nothing changed here. Oops, don't have SUNWmdb installed on the crash host. Look for Sol9 host with adb ... grumble ... grumble. OK, copied the dump files over and # adb -k unix.0 vmcore.0 physmem 3df9f adb: warning: dump is from SunOS 5.9 Generic_122300-31; dcmds and macros may not match kernel implementation 0x118b8a8/i bcopy+0x4b8: ld [%i0], %i4 Does that help? (I'm keeping the core files this time in case you ask something else). Joseph Tam <[email protected]>