and another one...
hi,
in net/bpf.c, bpfdetach(), stuct bpf_if *bp is used in a for loop, that,
if not terminated by break before, leaves bp == NULL.
evaluating (bp-bif_ifp == NULL) two lines later will cause a NULL pointer
dereference, resulting in trap 12.
please apply the attached patch.
best,
christian
--
Sorry, no defects found. Please try a different search
[http://www.cisco.com/support/bugtools/bugtool.shtml]
Index: bpf.c
===
RCS file: /usr/cvs/src/sys/net/bpf.c,v
retrieving revision 1.80
diff -r1.80 bpf.c
1267c1267
if (bp-bif_ifp == NULL) {
---
if (bp == NULL || bp-bif_ifp == NULL) {
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Here's another one for you...
SMP box with a bleeding-edge -CURRENT kernel, patched to avoid the
i586_bzero() problem:
panic: mutex_enter: recursion on non-recursive mutex process lock @
../../i386/i386/trap.c:854
cpuid = 1; lapic.id = 0100
Debugger("panic")
CPU1 stopping CPUs: 0x0001... stopped.
Stopped at Debugger+0x45: pushl %ebx
db show mutex
"panic" (0xc030b1e0) locked at ../../kern/kern_shutdown.c:544
"process lock" (0xd3f15000) locked at ../../i386/i386/machdep.c:625
"Giant" (0xc0309ac0) locked at ../../i386/i386/trap.c:1169
db trace
Debugger(c027d5e1) at Debugger+0x45
panic(c027c420,c027a154,c02997d0,356,d3f14ee0) at panic+0x144
witness_enter(d3f15000,0,c02997d0,356) at witness_enter+0x355
trap_pfault(d7345d4c,0,0) at trap_pfault+0x143
trap(18,10,10,d7345fa8,0) at trap+0x978
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0, esp = 0xd7345d8c, ebp = 0xd7345ed8 ---
(null)(805c3e0,e,d7345f10,0,4) at 0
postsig(e) at postsig+0x40b
userret(d3f14ee0,d7345fa8,3,0,) at userret+0x16
syscall(2f,2f,2f,bfbffd4c,80873e0) at syscall+0xa03
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
db show witness
Sleep mutexes:
0 rman -- last acquired @ ../../kern/subr_rman.c:420
0 rman head -- last acquired @ ../../kern/subr_rman.c:1070 sf_bufs list lock -- last
acquired @ ../../kern/uipc_syscalls.c:14370 vm86pcb lock -- last acquired @
../../i386/i386/vm86.c:5790 pseudofs -- last acquired @ order list:0
0 Giant -- last acquired @ ../../i386/i386/trap.c:1169
1 mbuf free list lock -- last acquired @ ../../kern/uipc_socket.c:870
1 fork list -- last acquired @ ../../kern/kern_sx.c:138
1 vnode pollinfo -- last acquired @ ../../kern/vfs_subr.c:2761
1 spechash -- last acquired @ ../../kern/vfs_subr.c:2003
1 bpf global lock -- last acquired @ ../../net/bpf.c:1221
1 mntid -- last acquired @ ../../kern/vfs_subr.c:426
2 mountlist -- last acquired @ ../../kern/vfs_subr.c:2872
3lockmgr interlock -- last acquired @ ../../kern/kern_lock.c:239
4 process lock -- last acquired @ ../../i386/i386/machdep.c:625
5 ucred -- last acquired @ ../../kern/kern_prot.c:1162
5 panic -- last acquired @ ../../kern/kern_shutdown.c:544
5 malloc -- last acquired @ ../../kern/kern_malloc.c:317
5 uidinfo hash -- last acquired @ ../../kern/kern_resource.c:745
6 uidinfo struct -- last acquired @ ../../kern/kern_resource.c:883
1 zone subsystem -- last acquired @ ../../vm/vm_zone.c:422
3lockmgr interlock -- last acquired @ ../../kern/kern_lock.c:239
4 process lock -- last acquired @ ../../i386/i386/machdep.c:625
5 ucred -- last acquired @ ../../kern/kern_prot.c:1162
5 panic -- last acquired @ ../../kern/kern_shutdown.c:544
5 malloc -- last acquired @ ../../kern/kern_malloc.c:317
5 uidinfo hash -- last acquired @ ../../kern/kern_resource.c:745
6 uidinfo struct -- last acquired @ ../../kern/kern_resource.c:883
2 zone -- last acquired @ ../../vm/vm_zone.c:366
3lockmgr -- last acquired @ ../../kern/kern_lock.c:505
4 process lock -- last acquired @ ../../i386/i386/machdep.c:625
5 ucred -- last acquired @ ../../kern/kern_prot.c:1162
5 panic -- last acquired @ ../../kern/kern_shutdown.c:544
5 malloc -- last acquired @ ../../kern/kern_malloc.c:317
5 uidinfo hash -- last acquired @ ../../kern/kern_resource.c:745
6 uidinfo struct -- last acquired @ ../../kern/kern_resource.c:883
1 de -- last acquired @ ../../pci/if_de.c:4653
1 ifsvgt -- last acquired @ ../../ufs/ffs/ffs_vfsops.c:1129
1 random reseed -- last acquired @ ../../dev/random/yarrow.c:265
1 ufs ihash -- last acquired @ ../../ufs/ufs/ufs_ihash.c:133
2 vnode interlock -- last acquired @ ../../kern/vfs_subr.c:1439
3vnode_free_list -- last acquired @ ../../kern/vfs_subr.c:542
3mntvnode -- last acquired @ ../../kern/vfs_subr.c:650
3lockmgr interlock -- last acquired @ ../../kern/kern_lock.c:239
4 process lock -- last acquired @ ../../i386/i386/machdep.c:625
5 ucred -- last acquired @ ../../kern/kern_prot.c:1162
5 panic -- last acquired @ ../../kern/kern_shutdown.c:544
5 malloc -- last acquired @ ../../kern/kern_malloc.c:317
5 uidinfo hash -- last acquired @ ../../kern/kern_resource.c:745
6 uidinfo struct -- last acquired @ ../../kern/kern_resource.c:883
1 m_ext counter free list lock -- last acquired @ ../../pci/if_de.c:3552
1 mcluster free list lock -- last acquired @ ../../pci/if_de.c:3552
1 buftime lock -- last acquired @ ../../sys/buf.h:255
3lockmgr interlock -- last acquired @ ../../kern/kern_lock.c:239
4 process lock -- last acquired @ ../../i386/i386/machdep.c:625
5 ucred -- last acquired @ ../../kern/kern_prot.c:1162
5 panic -- last acquired @ ../../kern/kern_shutdown.c:544
5 malloc -- last acquired @ ../../kern/kern_malloc.c:317
5 uidinfo hash -- last acquired @ ../../kern/kern_resource.c:745
6 uidinfo struct -- last acquired @ ../../kern/kern_resource.c:883
1 eventhandler -- last
Re: Here's another one for you...
Dag-Erling Smorgrav writes: db trace Debugger(c027d5e1) at Debugger+0x45 panic(c027c420,c027a154,c02997d0,356,d3f14ee0) at panic+0x144 witness_enter(d3f15000,0,c02997d0,356) at witness_enter+0x355 trap_pfault(d7345d4c,0,0) at trap_pfault+0x143 trap(18,10,10,d7345fa8,0) at trap+0x978 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0, esp = 0xd7345d8c, ebp = 0xd7345ed8 --- (null)(805c3e0,e,d7345f10,0,4) at 0 postsig(e) at postsig+0x40b userret(d3f14ee0,d7345fa8,3,0,) at userret+0x16 syscall(2f,2f,2f,bfbffd4c,80873e0) at syscall+0xa03 syscall_with_err_pushed() at syscall_with_err_pushed+0x1b db show witness Where does witness_enter+0x355 map to, in terms of line numbers? I'm seeing a really bizzare thing on alpha (UP, of course) where a process will occasional die with an instruction fault on an address in the kernel's text segment --- witness_exit (../../kern/kern_mutex.c:1262) The only reasonable way for this to happen is the stack getting corrupted and restoreregs() restoring a corrupt PC. I suspect there is some sort of stack smashing going on in the signal code there are different consequences on different platforms. If so, it looks like x86 might be a better place to debug it, since you seem to be crashing soon after the stack smash happens, not much latter like we are on alpha. The program that most easily exhibits this behaviour is a linux app, ex6 from the linux-threads examples. It basically sits in a loop doing a pthread_create()/pthread_join() of a thread which just exits. Since its linux threads, a lot of signals are flying around. I don't have an x86 running current. If you'd like to see if this provokes a similar crash for you, I've left an x86 binary of ex6 at http://www.cs.duke.edu/~gallatin/ex6.x86 Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Here's another one for you...
Andrew Gallatin [EMAIL PROTECTED] writes:
Where does witness_enter+0x355 map to, in terms of line numbers?
root@rsa /var/crash# gdb -k
GNU gdb 4.18
Copyright 1998 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 "i386-unknown-freebsd".
(kgdb) source ~des/kgdb
(kgdb) kernel 1
IdlePTD 3670016
initial pcb at 2dac80
panicstr: from debugger
panic messages:
---
panic: mutex_enter: recursion on non-recursive mutex process lock @
../../i386/i386/trap.c:854
cpuid = 1; lapic.id = 0100
"panic" (0xc030b1e0) locked at ../../kern/kern_shutdown.c:544
"process lock" (0xd3f15000) locked at ../../i386/i386/machdep.c:625
"Giant" (0xc0309ac0) locked at ../../i386/i386/trap.c:1169
panic: from debugger
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
Uptime: 22s
dumping to dev da3b, offset 1048576
dump 512 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493
492 491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 473 472
471 470 469 468 467 466 465 464 463 462 461 460 459 458 457 456 455 454 453 452 451
450 449 448 447 446 445 444 443 442 441 440 439 438 437 436 435 434 433 432 431 430
429 428 427 426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 409
408 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390 389 388
387 386 385 384 383 382 381 380 379 378 377 376 375 374 373 372 371 370 369 368 367
366 365 364 363 362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346
345 344 343 342 341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325
324 323 322 321 320 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304
303 302 301 300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283
282 281 280 279 278 277 276 275 274 273 272 271 270 269 268 267 !
266 265 264 263 262 261 260 259 258 257 256 255 254 253 252 251 250 249 248 247 246
245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225
224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204
203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183
182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162
161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141
140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120
119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98
97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69
68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40
39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11
10 9 8 7 6 5 4 3 2 1
---
#0 dumpsys () at ../../kern/kern_shutdown.c:478
478 return;
(kgdb) where
#0 dumpsys () at ../../kern/kern_shutdown.c:478
#1 0xc016e57f in boot (howto=260) at ../../kern/kern_shutdown.c:321
#2 0xc016ea1d in panic (fmt=0xc0275294 "from debugger")
at ../../kern/kern_shutdown.c:571
#3 0xc0130ce9 in db_panic (addr=-1071400491, have_addr=0, count=-1,
modif=0xd7345b4c "") at ../../ddb/db_command.c:433
#4 0xc0130c89 in db_command (last_cmdp=0xc02a6a54, cmd_table=0xc02a68b4,
aux_cmd_tablep=0xc02c7978) at ../../ddb/db_command.c:333
#5 0xc0130d4e in db_command_loop () at ../../ddb/db_command.c:455
#6 0xc0132f17 in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
#7 0xc023b6eb in kdb_trap (type=3, code=0, regs=0xd7345c4c)
at ../../i386/i386/db_interface.c:164
#8 0xc0250943 in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16,
tf_edi = -739132928, tf_esi = 256, tf_ebp = -684434280,
tf_isp = -684434312, tf_ebx = 514, tf_edx = 1017, tf_ecx = 1021,
tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1071400491, tf_cs = 8,
tf_eflags = 70, tf_esp = -1071027024, tf_ss = -1071131167})
at ../../i386/i386/trap.c:608
#9 0xc023b9d5 in Debugger (msg=0xc027d5e1 "panic") at machine/cpufunc.h:60
#10 0xc016ea14 in panic (
fmt=0xc027c420 "mutex_enter: recursion on non-recursive mutex %s @ %s:%d")
at ../../kern/kern_shutdown.c:569
#11 0xc0166271 in witness_enter (m=0xd3f15000, flags=0,
file=0xc02997d0 "../../i386/i386/trap.c", line=854)
at ../../kern/kern_mutex.c:1112
#12 0xc0250f0b in trap_pfault (frame=0xd7345d4c, usermode=0, eva=0)
at ../../i386/i386/trap.c:854
#13 0xc0250408 in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16,
tf_edi = -684433496, tf_esi = 0, tf_ebp = -684433704,
tf_isp = -684434056, tf_ebx = -739160352, tf_edx = -684433712,
tf_ecx = 0, tf_eax = -1071382469, tf_trapno = 12, tf_err = 0,
Re: Here's another one for you...
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: Andrew Gallatin [EMAIL PROTECTED] writes: Where does witness_enter+0x355 map to, in terms of line numbers? root@rsa /var/crash# gdb -k [...] Argh! Please ignore this, the machine gdb was running on had an old source tree. I'll get a correct backtrace as soon as I can transfer the kernel, core and symbol files to the machine I used to build the kernel. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Here's another one for you...
On 19-Mar-01 Dag-Erling Smorgrav wrote:
SMP box with a bleeding-edge -CURRENT kernel, patched to avoid the
i586_bzero() problem:
panic: mutex_enter: recursion on non-recursive mutex process lock @
../../i386/i386/trap.c:854
cpuid = 1; lapic.id = 0100
Debugger("panic")
That's a later symptom of a problem. We recursed on the proc lock doing the
PHOLD before we handled the page fault.
CPU1 stopping CPUs: 0x0001... stopped.
Stopped at Debugger+0x45: pushl %ebx
db show mutex
"panic" (0xc030b1e0) locked at ../../kern/kern_shutdown.c:544
"process lock" (0xd3f15000) locked at ../../i386/i386/machdep.c:625
This is in sendsig():
p = curproc;
PROC_LOCK(p);
psp = p-p_sigacts;
if (SIGISMEMBER(psp-ps_osigset, sig)) {
...
"Giant" (0xc0309ac0) locked at ../../i386/i386/trap.c:1169
db trace
Debugger(c027d5e1) at Debugger+0x45
panic(c027c420,c027a154,c02997d0,356,d3f14ee0) at panic+0x144
witness_enter(d3f15000,0,c02997d0,356) at witness_enter+0x355
trap_pfault(d7345d4c,0,0) at trap_pfault+0x143
trap(18,10,10,d7345fa8,0) at trap+0x978
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0, esp = 0xd7345d8c, ebp = 0xd7345ed8 ---
(null)(805c3e0,e,d7345f10,0,4) at 0
postsig(e) at postsig+0x40b
Hmmm. An eip of 0 is bad. This could be just another instance of the bzero
bug just in another place. You probably want to change the code that actually
sets *bzero to i586_bzero (and same for any other ops that use floating point).
The code in question for this lies in i386/isa/npx.c. It seems we use the fp
regs for copyin/copyout and bcopy as well. I would just change line 458 of
npx.c to say '#ifdef I586_CPU_XXX' for now as your temporary patch (then you
don't need to patch pmap_zero_page() anymore.)
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: Here's another one for you...
On Mon, 19 Mar 2001, John Baldwin wrote: Hmmm. An eip of 0 is bad. This could be just another instance of the bzero bug just in another place. You probably want to change the code that actually sets *bzero to i586_bzero (and same for any other ops that use floating point). The code in question for this lies in i386/isa/npx.c. It seems we use the fp regs for copyin/copyout and bcopy as well. I would just change line 458 of npx.c to say '#ifdef I586_CPU_XXX' for now as your temporary patch (then you don't need to patch pmap_zero_page() anymore.) There is no need to change anything. Just disable the fp optimizations using the npx flags. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Here's another one for you...
On 20-Mar-01 Bruce Evans wrote: On Mon, 19 Mar 2001, John Baldwin wrote: Hmmm. An eip of 0 is bad. This could be just another instance of the bzero bug just in another place. You probably want to change the code that actually sets *bzero to i586_bzero (and same for any other ops that use floating point). The code in question for this lies in i386/isa/npx.c. It seems we use the fp regs for copyin/copyout and bcopy as well. I would just change line 458 of npx.c to say '#ifdef I586_CPU_XXX' for now as your temporary patch (then you don't need to patch pmap_zero_page() anymore.) There is no need to change anything. Just disable the fp optimizations using the npx flags. That works, too, but until i586_* are fixed they need to default to off, not to on. :) I'm not suggesting committing this, just suggesting a local hack for testing anyways. Bruce -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Here's another one for you...
On Tue, 20 Mar 2001, Bruce Evans wrote: On Mon, 19 Mar 2001, John Baldwin wrote: Hmmm. An eip of 0 is bad. This could be just another instance of the bzero bug just in another place. You probably want to change the code that actually sets *bzero to i586_bzero (and same for any other ops that use floating point). The code in question for this lies in i386/isa/npx.c. It seems we use the fp regs for copyin/copyout and bcopy as well. I would just change line 458 of npx.c to say '#ifdef I586_CPU_XXX' for now as your temporary patch (then you don't need to patch pmap_zero_page() anymore.) There is no need to change anything. Just disable the fp optimizations using the npx flags. Actually, there may be. The bandwidth test gets run on 586's even if the flags say not to use the result. This is to provide a "free" bandwidth test. It was harmless when the fp code wasn't broken. The flags are mainly for disabling using the fp code for accesses to broken device memory (bcopy and/or bzero were (are?) abuses to access device memory, and some device memory doesn't like 64-bit accesses). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
