panic: vm_map.c:1119 - Githubissues

berkus / phantomuserland

Automatically exported from code.google.com/p/phantomuserland

0 stars 0 forks source link

panic: vm_map.c:1119 #151

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago

Running for a day on real pc: panic: vm_map.c:1119, vm_map_do_for_all: 
assertion !hal_mutex_is_locked(&i->lock) failed

Seems to be called from here:
    vm_map_for_all_locked( mark_for_snap );

Original issue reported on code.google.com by dmitry.zavalishin@gmail.com on 11 Oct 2011 at 7:47

GoogleCodeExporter commented 9 years ago

So, looks like there's someone else playing in the virtual memory area. 
Specifically, non-virtual machine thread.

First I wonder how this can be possible: the execution state of that thread is 
not tracked in the VM, so it cannot be restarted from snapshot. I guess that 
virtual machine thread that owns the buffer will treat its content as 
indeterminate and will have to restart its request to that non-virtual machine 
thread after restart from snapshot.

If so, then we can provide rw lock for the whole VM: ordinary threads will 
acquire it for reading and the snapper will acquire it for writing. Probably 
this r-acquisition may be done from the pagefault handlers.

If that makes sense I will try to implement it.

Original comment by jcmvb...@gmail.com on 12 Oct 2011 at 10:08

GoogleCodeExporter commented 9 years ago

Can it be some delayed pageing activity?

As for rw locks - we'll surely need 'em anyway, so I think implementing rw 
mutex is good idea in any case.

Original comment by d...@dz.ru on 14 Oct 2011 at 12:40

GoogleCodeExporter commented 9 years ago

Paging activity is synchronous and always belong to a thread.
So it can be whatever paging activity but not in virtual machine thread.

Original comment by jcmvb...@gmail.com on 14 Oct 2011 at 12:49

GoogleCodeExporter commented 9 years ago

io callbacks are async!

Original comment by d...@dz.ru on 14 Oct 2011 at 1:21

GoogleCodeExporter commented 9 years ago

Please correct me if I'm wrong:

IO by itself cannot raise a pagefault since it needs physical memory to start 
transfer to/from it.

IO callback that results from the pagein or pageout initiated by the pagefault 
is completely nested into the pagefault handler, so it is synchronous to its 
thread.

Original comment by jcmvb...@gmail.com on 14 Oct 2011 at 1:53

GoogleCodeExporter commented 9 years ago

I believe pageins are nested (thread waits for page), and pageouts are not - 
thread is free to go...

Original comment by d...@dz.ru on 14 Oct 2011 at 2:55

GoogleCodeExporter commented 9 years ago

Thanks, I need to review it in greater detail.

Original comment by jcmvb...@gmail.com on 14 Oct 2011 at 3:02