At a 32 bit UML guest with recent kernel one of the processes became a zombie
wgile fuzz testing with trinity:
The UML guest itself runs somehow but ssh into it was no longer possible.
The trinity log doesn't gave any info about that particular process, gdb tells :
tfoerste@n22 ~ $ date; pgrep -af 'linux earlyprintk' | cut -f1 -d' ' | xargs
-n1 gdb /home/tfoerste/devel/linux/linux -n -batch -ex 'bt'
Fri May 9 18:40:18 CEST 2014
Program received signal SIGSEGV, Segmentation fault.
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
show_stack (task=0x0, stack=0x0) at arch/um/kernel/sysrq.c:93
93 printk(KERN_CONT " %08lx", *stack++);
#0 show_stack (task=0x0, stack=0x0) at arch/um/kernel/sysrq.c:93
#1 0x084eb015 in __dump_stack () at lib/dump_stack.c:15
#2 dump_stack () at lib/dump_stack.c:60
#3 0x084e7bda in dump_header (gfp_mask=0, order=1, memcg=0x0,
nodemask=<optimized out>, p=<optimized out>) at mm/oom_kill.c:400
#4 0x080cfe03 in oom_kill_process (p=0x4534a080, gfp_mask=131546, order=0,
points=0, totalpages=321692, memcg=0x0, nodemask=0x0, message=0x0) at
mm/oom_kill.c:438
#5 0x080d0572 in out_of_memory (zonelist=0x86f1d50 <contig_page_data+1392>,
gfp_mask=131546, order=0, nodemask=0x0, force_kill=96) at mm/oom_kill.c:672
#6 0x080d3c74 in __alloc_pages_may_oom (migratetype=<optimized out>,
preferred_zone=<optimized out>, nodemask=<optimized out>,
high_zoneidx=<optimized out>, zonelist=<optimized out>, order=<optimized out>,
gfp_mask=<optimized out>) at mm/page_alloc.c:2216
#7 __alloc_pages_slowpath (migratetype=<optimized out>,
preferred_zone=0x86f17e0 <contig_page_data>, nodemask=<optimized out>,
high_zoneidx=<optimized out>, zonelist=<optimized out>, order=<optimized out>,
gfp_mask=<optimized out>) at mm/page_alloc.c:2623
#8 __alloc_pages_nodemask (gfp_mask=141498336, order=0, zonelist=0x86f1d50
<contig_page_data+1392>, nodemask=0x0) at mm/page_alloc.c:2768
#9 0x080cd6e3 in __alloc_pages (zonelist=<optimized out>, order=<optimized
out>, gfp_mask=<optimized out>) at include/linux/gfp.h:312
#10 alloc_pages_node (order=<optimized out>, gfp_mask=<optimized out>,
nid=<optimized out>) at include/linux/gfp.h:322
#11 __page_cache_alloc (gfp=<optimized out>) at include/linux/pagemap.h:235
#12 page_cache_alloc_cold (x=<optimized out>) at include/linux/pagemap.h:246
#13 page_cache_read (offset=<optimized out>, file=<optimized out>) at
mm/filemap.c:1794
#14 filemap_fault (vma=0x45317220, vmf=0x4762fd08) at mm/filemap.c:1969
#15 0x080e70cf in __do_fault (vma=0x0, address=1, pgoff=2768, flags=1,
page=0x1) at mm/memory.c:3346
#16 0x080e96e6 in do_read_fault (vma=0x45317220, address=1075365528,
pmd=0x45135400, pgoff=355, flags=168, orig_pte=<incomplete type>, mm=<optimized
out>) at mm/memory.c:3526
#17 0x080e9e63 in do_nonlinear_fault (orig_pte=..., flags=1584, pmd=<optimized
out>, address=<optimized out>, vma=<optimized out>, mm=<optimized out>,
page_table=<optimized out>) at mm/memory.c:3695
#18 handle_pte_fault (flags=<optimized out>, pmd=<optimized out>,
pte=<optimized out>, address=<optimized out>, vma=<optimized out>,
mm=<optimized out>) at mm/memory.c:3825
#19 __handle_mm_fault (flags=<optimized out>, address=<optimized out>,
vma=<optimized out>, mm=<optimized out>) at mm/memory.c:3945
#20 handle_mm_fault (mm=0x39f1fb00, vma=0x45317220, address=1075365528,
flags=168) at mm/memory.c:3968
#21 0x08061d5a in handle_page_fault (address=1075365528, ip=1074507991,
is_write=0, is_user=1, code_out=0x4762fe40) at arch/um/kernel/trap.c:75
#22 0x08061f8e in segv (fi=<incomplete type>, ip=1074507991, is_user=1,
regs=0x4534afe0) at arch/um/kernel/trap.c:222
#23 0x08062233 in segv_handler (sig=11, unused_si=0x4762ff5c, regs=0x4534afe0)
at arch/um/kernel/trap.c:191
#24 0x0807470a in userspace (regs=0x4534afe0) at
arch/um/os-Linux/skas/process.c:420
#25 0x0805f770 in fork_handler () at arch/um/kernel/process.c:149
#26 0x00000000 in ?? ()
I'm unsure if this is worth to be reported or just another incarnation of an
already observed/discussed issue - but who knows ?
--
Toralf
------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
