Re: lockmgr panic with mmap()
On Thu, Mar 04, 1999 at 02:40:14AM +0900, Daniel C. Sobral wrote: > > And the question is how he managed to. :-) > I graduated from CMU in 1986. While there, I worked part-time on the Mach project. Later, I used the Mach VM code as infrastructure for my Ph.D. thesis on automatic data placement for NUMA multiprocessors. That's probably not what you wanted to hear. :-) In any case, if you and Brian (and others) want to learn more, so that you can contribute, I'll gladly help you. Alan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: lockmgr panic with mmap()
"John S. Dyson" wrote: > > Brian Feldman said: > > > > Quick question: how in the heck did you learn this whole VM system? > Alan has had a history helping on the VM code for quite a while, and > has contributed some really good ideas. Frankly, he appears to > understand the code as well as anyone does. And the question is how he managed to. :-) -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org "FreeBSD is Yoda, Linux is Luke Skywalker." To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: lockmgr panic with mmap()
Brian Feldman said: > > > > The lock manager isn't bright enough to detect that the process > > already holds a read lock when it attempts to get the write lock. > > Thus, you get the "thrd_sleep" instead of a panic. > > > > In short, same bug, different symptoms. > > > Ahh, makes sense. > > Quick question: how in the heck did you learn this whole VM system? > Alan has had a history helping on the VM code for quite a while, and has contributed some really good ideas. Frankly, he appears to understand the code as well as anyone does. -- John | Never try to teach a pig to sing, dy...@iquest.net | it makes one look stupid jdy...@nc.com | and it irritates the pig. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: lockmgr panic with mmap()
On Tue, 2 Mar 1999, Alan Cox wrote: > On Tue, Mar 02, 1999 at 06:16:50PM -0500, Brian Feldman wrote: > > > > Where exactly does thrd_sleep come in, since that's where the program locks > > up now? Can't be killed, of course... > > > > The lock manager isn't bright enough to detect that the process > already holds a read lock when it attempts to get the write lock. > Thus, you get the "thrd_sleep" instead of a panic. > > In short, same bug, different symptoms. > Ahh, makes sense. Quick question: how in the heck did you learn this whole VM system? Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: lockmgr panic with mmap()
On Tue, Mar 02, 1999 at 06:16:50PM -0500, Brian Feldman wrote: > > Where exactly does thrd_sleep come in, since that's where the program locks > up now? Can't be killed, of course... > The lock manager isn't bright enough to detect that the process already holds a read lock when it attempts to get the write lock. Thus, you get the "thrd_sleep" instead of a panic. In short, same bug, different symptoms. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: lockmgr panic with mmap()
On Tue, 2 Mar 1999, Alan Cox wrote: > On Tue, Mar 02, 1999 at 10:41:46PM +1100, Bruce Evans wrote: > > > > Doesn't it modify the map indirectly vi subyte()? I think it wants > > to prevent modifications, but this is impossible. > > > > Bear with me, I'll have to split some hairs... > > We're only interested in whether mincore directly changes the vm_map, > literally modifying a vm_map_entry, etc. subyte is writing to memory, > not a vm_map_entry. subyte is only indirectly changing the map > because a page fault occurs. That page fault *is* (frequently) changing > the map, and we're deadlocking when it attempts to acquire the write lock > on the map. > > Basically, what I believe that you suggested yesterday, that mincore > release the lock around the subyte is correct. Code will > appear shortly... Where exactly does thrd_sleep come in, since that's where the program locks up now? Can't be killed, of course... > > Alan > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: lockmgr panic with mmap()
On Tue, Mar 02, 1999 at 10:41:46PM +1100, Bruce Evans wrote: > > Doesn't it modify the map indirectly vi subyte()? I think it wants > to prevent modifications, but this is impossible. > Bear with me, I'll have to split some hairs... We're only interested in whether mincore directly changes the vm_map, literally modifying a vm_map_entry, etc. subyte is writing to memory, not a vm_map_entry. subyte is only indirectly changing the map because a page fault occurs. That page fault *is* (frequently) changing the map, and we're deadlocking when it attempts to acquire the write lock on the map. Basically, what I believe that you suggested yesterday, that mincore release the lock around the subyte is correct. Code will appear shortly... Alan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: lockmgr panic with mmap()
>Until you modify the map, an exclusive lock on the map is overkill. Try >using read locks. (See vm_map_lookup.) > >In the meantime, I can't see any reason why mincore acquires an >exclusive lock either. (It never modifies the map.) I'm going >to remedy that. Doesn't it modify the map indirectly vi subyte()? I think it wants to prevent modifications, but this is impossible. Bruce To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: lockmgr panic with mmap()
Admittedly detecting deadlock is not trivial in general. But if we are about to panic because of deadlock, then we have already detected something. The question now is: Do we crash the whole system, or just one or two user processes? Rahul > :Since bugs do happen, deadlock can occur in the kernel. > : > :Is it not possible in such cases to simply detect the deadlock, and kill > :one of the user processes involved in the deadlock, thus releasing one > :of the resources involved in the deadlock? Then you would log > :diagnostic information and let the system continue normally > Most of the deadlocks remaining in the kernel are more complex and often > cannot be detected without significant new work > Detecting the loop is the hard part. This is known as 'deadlock > detection'... ... > In FreeBSD's case, the issue is somewhat more complex due to things > that are not strictly locks causing deadlocks - such as a low memory > condition causing a process holding an inode lock to block and then the > syncer blocking on the same inode. The syncer is thus unable to run and > thus unable to sync the dirty buffers clogging memory to disk. Things > like that. > > -Matt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: lockmgr panic with mmap()
Until you modify the map, an exclusive lock on the map is overkill. Try using read locks. (See vm_map_lookup.) In the meantime, I can't see any reason why mincore acquires an exclusive lock either. (It never modifies the map.) I'm going to remedy that. Alan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: lockmgr panic with mmap()
> The question is whether there is a way to do the autogrow function if > the map lock is already held. > Allow lock recurse? -lq To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: lockmgr panic with mmap()
>> mincore() locks the vmspace map, and initialises vec[] a byte at a time >> using subyte(). When vec[] is sufficiently large, it is not all in core >> initially and a page fault occurs in subyte(). The new stack growing >> code locks the vmspace map early and panics. > >It appears to me the potential for deadlock exists in the old grow code >too, but is less likely. > >I've attached a patch that addresses the issue, though there is a >question if this is the best solution. > >With the old grow code, if the map lock is already held, one of the >following will be true >a) the grow code doesn't get executed because the va is not > in the stack region, which is equivalent to grow returning > success >b) the grow code returns success because there's no need to > grow the region because the va is aready in the mapped region. >c) the grow code returns false if the va is within the stack > region and there's no room left, which normally will result > in a SIGSEGV >d) the grow code attempts to grow the stack via vm_map_find and > will then deadlock at the vm_map_lock call > >With this patch, if the map lock is already held, by always returning >success, cases a) and b) will be the same as before. For case c) >the code will attempt to continue to execute, generally calling >vm_fault, which should, I think, generate a SIGSEGV, essentially >the same result as the old code, but via a different path. Case d) >will now continue executing in a manner equivalent to the new case c). > >The question is whether there is a way to do the autogrow function if >the map lock is already held. I think it shouldn't work. Copying to and from user space must not generate SIGSEGV if the application could access its memory directly. The easiest way to implement this is to never lock maps before accessing user memory. Atomic copies won't get any easier to do after you've backed out of a deadlock. I think mincore() should just unlock the map while calling subyte() and restart if the map changes significantly underneath it. Some critical examples: 1. mincore(addr, 0xfff0, vec) at rtprio 0 (in only process with this priority). vec[] only needs to have size 1MB (for 4K pages). It's barely reasonable for the application to expect vec[] to be all mapped and to perfectly represent the current state. To implement this, mincore() would have to prefault vec[] (or backtrack to give the equivalent) so that it doesn't block. 2. mincore(vec, len, vec). This is quite likely to change the incore'ness of vec[]. Bruce To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: lockmgr panic with mmap()
On Sun, Feb 28, 1999 at 11:52:57PM +1100, Bruce Evans wrote:
[snip]
> Here is a simpler example.
>
> ---
> #include
> #include
>
> #include
> #include
>
> #define SIZE(32 * 1024 * 1024)
>
> int
> main(void)
> {
> void *p;
> char vec[SIZE / PAGE_SIZE];
>
> p = malloc(SIZE);
> if (mincore(p, SIZE, vec) != 0)
> err(1, "mincore");
> return (0);
> }
> ---
>
> mincore() locks the vmspace map, and initialises vec[] a byte at a time
> using subyte(). When vec[] is sufficiently large, it is not all in core
> initially and a page fault occurs in subyte(). The new stack growing
> code locks the vmspace map early and panics.
It appears to me the potential for deadlock exists in the old grow code
too, but is less likely.
I've attached a patch that addresses the issue, though there is a
question if this is the best solution.
With the old grow code, if the map lock is already held, one of the
following will be true
a) the grow code doesn't get executed because the va is not
in the stack region, which is equivalent to grow returning
success
b) the grow code returns success because there's no need to
grow the region because the va is aready in the mapped region.
c) the grow code returns false if the va is within the stack
region and there's no room left, which normally will result
in a SIGSEGV
d) the grow code attempts to grow the stack via vm_map_find and
will then deadlock at the vm_map_lock call
With this patch, if the map lock is already held, by always returning
success, cases a) and b) will be the same as before. For case c)
the code will attempt to continue to execute, generally calling
vm_fault, which should, I think, generate a SIGSEGV, essentially
the same result as the old code, but via a different path. Case d)
will now continue executing in a manner equivalent to the new case c).
The question is whether there is a way to do the autogrow function if
the map lock is already held.
--
Richard Seaman, Jr. email: d...@tar.com
5182 N. Maple Lanephone: 414-367-5450
Chenequa WI 53058 fax: 414-367-5850Index: vm_map.c
===
RCS file: /home/ncvs/src/sys/vm/vm_map.c,v
retrieving revision 1.152
diff -c -r1.152 vm_map.c
*** vm_map.c1999/02/24 21:26:25 1.152
--- vm_map.c1999/02/28 20:41:25
***
*** 663,668
--- 663,674
int rv;
int is_procstack = 0;
+
+ #define vm_map_locked(map) lockstatus(&(map)->lock)
+
+ if (vm_map_locked(map))
+ return (KERN_SUCCESS);
+
vm_map_lock(map);
/* If addr is already in the entry range, no need to grow.*/
Re: lockmgr panic with mmap()
:Please forgive me if this is a silly question. : :Since bugs do happen, deadlock can occur in the kernel. : :Is it not possible in such cases to simply detect the deadlock, and kill :one of the user processes involved in the deadlock, thus releasing one :of the resources involved in the deadlock? Then you would log :diagnostic information and let the system continue normally. If a user :deliberately does something to deadlock the kernel, his process just :gets killed and a denial-of-service attack has been averted. : :As I vaguely recall, VAX/VMS used to do soemthing like this if a :deadlock was detected. : :Rahul Well, the lockmgr panic with mmap() is something that ought to be easily fixable ( by whoever did the stack changes ). There are also deadlock problems when read()ing or write()ing a file-backed mmap()'d area. Most of the deadlocks remaining in the kernel are more complex and often cannot be detected without significant new work. For example, there is no tracking of the PIDs holding shared locks, only exclusive locks. Deadlocks can occur due to chains of locks across multiple processes ( e.g. 5 or 6 or more ) that loop back in on themselves. Detecting the loop is the hard part. This is known as 'deadlock detection'. It's the same sort of deadlock detection commercial SQL databases use to implement transactions and rollback. In FreeBSD's case, the issue is somewhat more complex due to things that are not strictly locks causing deadlocks - such as a low memory condition causing a process holding an inode lock to block and then the syncer blocking on the same inode. The syncer is thus unable to run and thus unable to sync the dirty buffers clogging memory to disk. Things like that. -Matt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: lockmgr panic with mmap()
Please forgive me if this is a silly question.
Since bugs do happen, deadlock can occur in the kernel.
Is it not possible in such cases to simply detect the deadlock, and kill
one of the user processes involved in the deadlock, thus releasing one
of the resources involved in the deadlock? Then you would log
diagnostic information and let the system continue normally. If a user
deliberately does something to deadlock the kernel, his process just
gets killed and a denial-of-service attack has been averted.
As I vaguely recall, VAX/VMS used to do soemthing like this if a
deadlock was detected.
Rahul
> Date: Sun, 28 Feb 99 23:52:57 +1100
> From: Bruce Evans
> To:curr...@freebsd.org, pango...@home.com
> Message-Id: <199902281252.xaa24...@godzilla.zeta.org.au>
> Subject: Re: lockmgr panic with mmap()
> >The attached program sometimes causes a lockmgr panic. I do not think is
> >always
> >did. I am running 4.0-CURRENT form Feb 19.
> >
> >The trace is:
> >panic lockmgr: locking against self
> >lockmgr
> >mv_map_growstack
> >grow_stack
> >trap_pfault
> >trap
> >calltrap
> >subyte
> >syscall
> >...
> >
> >A command on a running image such as this usually does it, though I do not
> >know what
> >conditions are neccessary:
> >
> >fincore /usr/local/netscape-4.5/communicator-4.5.bin
>
> Here is a simpler example.
>
> ---
> #include
> #include
>
> #include
> #include
>
> #define SIZE(32 * 1024 * 1024)
>
> int
> main(void)
> {
> void *p;
> char vec[SIZE / PAGE_SIZE];
>
> p = malloc(SIZE);
> if (mincore(p, SIZE, vec) != 0)
> err(1, "mincore");
> return (0);
> }
> ---
>
> mincore() locks the vmspace map, and initialises vec[] a byte at a time
> using subyte(). When vec[] is sufficiently large, it is not all in core
> initially and a page fault occurs in subyte(). The new stack growing
> code locks the vmspace map early and panics.
>
> Bruce
>
>
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
>
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: lockmgr panic with mmap()
>The attached program sometimes causes a lockmgr panic. I do not think is always
>did. I am running 4.0-CURRENT form Feb 19.
>
>The trace is:
>panic lockmgr: locking against self
>lockmgr
>mv_map_growstack
>grow_stack
>trap_pfault
>trap
>calltrap
>subyte
>syscall
>...
>
>A command on a running image such as this usually does it, though I do not
>know what
>conditions are neccessary:
>
>fincore /usr/local/netscape-4.5/communicator-4.5.bin
Here is a simpler example.
---
#include
#include
#include
#include
#define SIZE(32 * 1024 * 1024)
int
main(void)
{
void *p;
char vec[SIZE / PAGE_SIZE];
p = malloc(SIZE);
if (mincore(p, SIZE, vec) != 0)
err(1, "mincore");
return (0);
}
---
mincore() locks the vmspace map, and initialises vec[] a byte at a time
using subyte(). When vec[] is sufficiently large, it is not all in core
initially and a page fault occurs in subyte(). The new stack growing
code locks the vmspace map early and panics.
Bruce
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: lockmgr panic with mmap() (fwd)
>
> The attached program sometimes causes a lockmgr panic. I do not think is
> always
> did. I am running 4.0-CURRENT form Feb 19.
>
> The trace is:
> panic lockmgr: locking against self
> lockmgr
> mv_map_growstack
> grow_stack
> trap_pfault
> trap
> calltrap
> subyte
> syscall
> ...
>
> A command on a running image such as this usually does it, though I do not
> know what
> conditions are neccessary:
>
> fincore /usr/local/netscape-4.5/communicator-4.5.bin
>
> Jonathan Hanna
>
>
Yep, this is reproducible :(
GDB is free software and you are welcome to 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.
GDB 4.16 (i386-unknown-freebsd),
Copyright 1996 Free Software Foundation, Inc...
IdlePTD 2875392
initial pcb at 23ef40
panicstr: lockmgr: locking against myself
panic messages:
---
panic: lockmgr: locking against myself
syncing disks... 10 10 6 done
dumping to dev 20001, offset 73728
dump 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 boot (howto=256) at ../../kern/kern_shutdown.c:287
287 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:287
#1 0xf0137821 in panic (fmt=0xf0206116 "lockmgr: locking against myself")
at ../../kern/kern_shutdown.c:448
#2 0xf0133738 in lockmgr (lkp=0xf5f5f280, flags=2, interlkp=0x0, p=0xf5f688e0)
at ../../kern/kern_lock.c:320
#3 0xf01a5b25 in vm_map_growstack (p=0xf5f688e0, addr=134524928)
at ../../vm/vm_map.c:666
#4 0xf01dc52a in grow_stack (p=0xf5f688e0, sp=134524928)
at ../../i386/i386/vm_machdep.c:571
#5 0xf01d836f in trap_pfault (frame=0xf5f70ec8, usermode=0, eva=134524928)
at ../../i386/i386/trap.c:808
#6 0xf01d806e in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -1,
tf_esi = 0, tf_ebp = -168358064, tf_isp = -168358160,
tf_ebx = 672337920, tf_edx = 134524928, tf_ecx = -168366080, tf_eax = 1,
tf_trapno = 12, tf_err = 2, tf_eip = -266506240, tf_cs = 8,
tf_eflags = 66067, tf_esp = -266694180, tf_ss = 134524928})
at ../../i386/i386/trap.c:437
#7 0xf01d7000 in suibyte ()
#8 0xf01d899f in syscall (frame={tf_es = 47, tf_ds = 47, tf_edi = 321312,
tf_esi = 134524928, tf_ebp = -272640092, tf_isp = -168357932,
tf_ebx = -272640036, tf_edx = 7, tf_ecx = 7, tf_eax = 78,
tf_trapno = 12, tf_err = 2, tf_eip = 671697364, tf_cs = 31,
tf_eflags = 582, tf_esp = -272640248, tf_ss = 47})
at ../../i386/i386/trap.c:1100
#9 0xf01cb69c in Xint0x80_syscall ()
#10 0x80485d1 in ?? ()
(kgdb) frame 8
#8 0xf01d899f in syscall (frame={tf_es = 47, tf_ds = 47, tf_edi = 321312,
tf_esi = 134524928, tf_ebp = -272640092, tf_isp = -168357932,
tf_ebx = -272640036, tf_edx = 7, tf_ecx = 7, tf_eax = 78,
tf_trapno = 12, tf_err = 2, tf_eip = 671697364, tf_cs = 31,
tf_eflags = 582, tf_esp = -272640248, tf_ss = 47})
at ../../i386/i386/trap.c:1100
1100error = (*callp->sy_call)(p, args);
(kgdb) print callp
$1 = (struct sysent *) 0x0
(kgdb) quit
Brian Feldman_ __ ___ ___ ___
gr...@unixhelp.org _ __ ___ | _ ) __| \
http://www.freebsd.org/ _ __ ___ | _ \__ \ |) |
FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: lockmgr panic with mmap()
On Sat, 27 Feb 1999, Jonathan Hanna wrote:
>
> The attached program sometimes causes a lockmgr panic. I do not think is
> always
> did. I am running 4.0-CURRENT form Feb 19.
>
> The trace is:
> panic lockmgr: locking against self
> lockmgr
> mv_map_growstack
> grow_stack
> trap_pfault
> trap
> calltrap
> subyte
> syscall
> ...
>
> A command on a running image such as this usually does it, though I do not
> know what
> conditions are neccessary:
>
> fincore /usr/local/netscape-4.5/communicator-4.5.bin
>
> Jonathan Hanna
>
>
GDB is free software and you are welcome to 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.
GDB 4.16 (i386-unknown-freebsd),
Copyright 1996 Free Software Foundation, Inc...
IdlePTD 2875392
initial pcb at 23ef40
panicstr: lockmgr: locking against myself
panic messages:
---
panic: lockmgr: locking against myself
syncing disks... 10 10 6 done
dumping to dev 20001, offset 73728
dump 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 boot (howto=256) at ../../kern/kern_shutdown.c:287
287 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:287
#1 0xf0137821 in panic (fmt=0xf0206116 "lockmgr: locking against myself")
at ../../kern/kern_shutdown.c:448
#2 0xf0133738 in lockmgr (lkp=0xf5f5f280, flags=2, interlkp=0x0, p=0xf5f688e0)
at ../../kern/kern_lock.c:320
#3 0xf01a5b25 in vm_map_growstack (p=0xf5f688e0, addr=134524928)
at ../../vm/vm_map.c:666
#4 0xf01dc52a in grow_stack (p=0xf5f688e0, sp=134524928)
at ../../i386/i386/vm_machdep.c:571
#5 0xf01d836f in trap_pfault (frame=0xf5f70ec8, usermode=0, eva=134524928)
at ../../i386/i386/trap.c:808
#6 0xf01d806e in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -1,
tf_esi = 0, tf_ebp = -168358064, tf_isp = -168358160,
tf_ebx = 672337920, tf_edx = 134524928, tf_ecx = -168366080, tf_eax = 1,
tf_trapno = 12, tf_err = 2, tf_eip = -266506240, tf_cs = 8,
tf_eflags = 66067, tf_esp = -266694180, tf_ss = 134524928})
at ../../i386/i386/trap.c:437
#7 0xf01d7000 in suibyte ()
#8 0xf01d899f in syscall (frame={tf_es = 47, tf_ds = 47, tf_edi = 321312,
tf_esi = 134524928, tf_ebp = -272640092, tf_isp = -168357932,
tf_ebx = -272640036, tf_edx = 7, tf_ecx = 7, tf_eax = 78,
tf_trapno = 12, tf_err = 2, tf_eip = 671697364, tf_cs = 31,
tf_eflags = 582, tf_esp = -272640248, tf_ss = 47})
at ../../i386/i386/trap.c:1100
#9 0xf01cb69c in Xint0x80_syscall ()
#10 0x80485d1 in ?? ()
(kgdb) frame 8
#8 0xf01d899f in syscall (frame={tf_es = 47, tf_ds = 47, tf_edi = 321312,
tf_esi = 134524928, tf_ebp = -272640092, tf_isp = -168357932,
tf_ebx = -272640036, tf_edx = 7, tf_ecx = 7, tf_eax = 78,
tf_trapno = 12, tf_err = 2, tf_eip = 671697364, tf_cs = 31,
tf_eflags = 582, tf_esp = -272640248, tf_ss = 47})
at ../../i386/i386/trap.c:1100
1100error = (*callp->sy_call)(p, args);
(kgdb) print callp
$1 = (struct sysent *) 0x0
(kgdb) quit
Brian Feldman_ __ ___ ___ ___
gr...@unixhelp.org _ __ ___ | _ ) __| \
http://www.freebsd.org/ _ __ ___ | _ \__ \ |) |
FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
lockmgr panic with mmap()
The attached program sometimes causes a lockmgr panic. I do not think is always did. I am running 4.0-CURRENT form Feb 19. The trace is: panic lockmgr: locking against self lockmgr mv_map_growstack grow_stack trap_pfault trap calltrap subyte syscall ... A command on a running image such as this usually does it, though I do not know what conditions are neccessary: fincore /usr/local/netscape-4.5/communicator-4.5.bin Jonathan Hanna fincore.c Description: fincore.c
