search for: read_thread

Hi all, I think this is a serious bug, existing in the pvops 2.6.31.13 (also existing in linux 2.6.35); In the xenbus driver (drivers/xen/xenfs/xenbus.c), the function of xenbus_file_read has a section of source code like this: if (ret != sz) { if (i == 0) i = -EFAULT; goto out; } /* Clear

A pair of patches to the xenstore library that: 1) blocks signal delivery before creating the watch wakeup thread 2) reduces the stack size of the watch wakeup thread.

...9F27: main_create (xl_cmdimpl.c:4407) ==5722== by 0x804E119: main (xl.c:360) ==5722== ==5722== 28 bytes in 1 blocks are definitely lost in loss record 39 of 72 ==5722== at 0x4026B2D: malloc (vg_replace_malloc.c:299) ==5722== by 0x4279EBB: read_message (xs.c:1143) ==5722== by 0x427A89B: read_thread (xs.c:1219) ==5722== by 0x40E7953: start_thread (pthread_create.c:304) ==5722== by 0x41CF95D: clone (clone.S:130) And the bootloader one appears to increase with each reboot. FTR I did: valgrind --leak-check=full xl cr -F /etc/xen/d32-1 (-F runs xl in the foreground, so this won...

...;> #2 read_all (fd=26, data=data@entry =0x7f18d4000c50, len=len@entry =16, >> nonblocking=nonblocking@entry =0) at xs.c:374 >> #3 0x00007f18f8c41675 in read_message (h=h@entry =0x7f18e8001070, >> nonblocking=nonblocking@entry =0) at xs.c:1139 >> #4 0x00007f18f8c41e90 in read_thread (arg=0x7f18e8001070) at xs.c:1211 >> #5 0x00007f1906e5ff35 in start_thread (arg=0x7f190893d700) at >> pthread_create.c:309 >> #6 0x00007f1906787c3d in clone () at >> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 >> >> and then bt full: >> >> (gdb) b...

..., __fd=26) at /usr/include/bits/unistd.h:44 #2 read_all (fd=26, data=data@entry =0x7f18d4000c50, len=len@entry =16, nonblocking=nonblocking@entry =0) at xs.c:374 #3 0x00007f18f8c41675 in read_message (h=h@entry =0x7f18e8001070, nonblocking=nonblocking@entry =0) at xs.c:1139 #4 0x00007f18f8c41e90 in read_thread (arg=0x7f18e8001070) at xs.c:1211 #5 0x00007f1906e5ff35 in start_thread (arg=0x7f190893d700) at pthread_create.c:309 #6 0x00007f1906787c3d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 and then bt full: (gdb) bt full #0 0x00007f1906e6684d in read () at ../sysdeps/unix/syscall-templ...

...usr/include/bits/unistd.h:44 > #2 read_all (fd=26, data=data@entry =0x7f18d4000c50, len=len@entry =16, nonblocking=nonblocking@entry =0) at xs.c:374 > #3 0x00007f18f8c41675 in read_message (h=h@entry =0x7f18e8001070, nonblocking=nonblocking@entry =0) at xs.c:1139 > #4 0x00007f18f8c41e90 in read_thread (arg=0x7f18e8001070) at xs.c:1211 > #5 0x00007f1906e5ff35 in start_thread (arg=0x7f190893d700) at pthread_create.c:309 > #6 0x00007f1906787c3d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 > > and then bt full: > > (gdb) bt full > #0 0x00007f1906e6684d in read ()...

...l (fd=26, data=data@entry =0x7f18d4000c50, len=len@entry =16, >>> nonblocking=nonblocking@entry =0) at xs.c:374 >>> #3 0x00007f18f8c41675 in read_message (h=h@entry =0x7f18e8001070, >>> nonblocking=nonblocking@entry =0) at xs.c:1139 >>> #4 0x00007f18f8c41e90 in read_thread (arg=0x7f18e8001070) at xs.c:1211 >>> #5 0x00007f1906e5ff35 in start_thread (arg=0x7f190893d700) at >>> pthread_create.c:309 >>> #6 0x00007f1906787c3d in clone () at >>> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 >>> >>> and then bt full: &...

...c:4407) > ==5722== by 0x804E119: main (xl.c:360) > ==5722== > ==5722== 28 bytes in 1 blocks are definitely lost in loss record 39 of 72 > ==5722== at 0x4026B2D: malloc (vg_replace_malloc.c:299) > ==5722== by 0x4279EBB: read_message (xs.c:1143) > ==5722== by 0x427A89B: read_thread (xs.c:1219) > ==5722== by 0x40E7953: start_thread (pthread_create.c:304) > ==5722== by 0x41CF95D: clone (clone.S:130) I've posted a fix for this upstream: http://lists.xen.org/archives/html/xen-devel/2014-11/msg00542.html I've requested that it go into the next 4.4.x release....

Hi Michal, thank you for your answer. so if i understand that correctly, no matter if i shutdown or destroy the domain and no matter if it is a transient or an persistent vm, the thread should disappear, right? in my case they still exist, also an hour after i destroy the domain (and don´t start any new one). i use libvirt-1.1.35 on fedora core 20, for information. all the best max    

Package: xen-utils-4.4 Version: 4.4.1-3 When booting domU's running amd64 jessie, I notice some memory problems with xl. root at xen:~# pmap -x 4121 4121: /usr/lib/xen-4.4/bin/xl create --quiet --defconfig /etc/xen/auto/mail_deb80.cfg Address Kbytes RSS Dirty Mode Mapping 0000000000400000 144 128 0 r-x-- xl 0000000000623000 4 4 4 r---- xl

...u/libpthread.so.0 #1 0x00007fc32b1555c4 in read_all (fd=26, data=0x7fc3380e0a70, data@entry=0x20, len=len@entry=16, nonblocking=nonblocking@entry=0) at xs.c:365 #2 0x00007fc32b1556d8 in read_message (h=h@entry=0x7fc324013ee0, nonblocking=nonblocking@entry=0) at xs.c:1071 #3 0x00007fc32b156005 in read_thread (arg=0x7fc324013ee0) at xs.c:1137 #4 0x00007fc335097b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #5 0x00007fc3349daa3d in clone () from /lib/x86_64-linux-gnu/libc.so.6 #6 0x0000000000000000 in ?? () Thread 11 (Thread 0x7fc330e7f700 (LWP 29170)): #0 0x00007fc33509c2d4 in pt...

I am newbie to this gdb debugging. now i did the bt in the debugging. In my side still it showing the error. Following are the stacktrace which i got. Kindly refer the following logs for full information: **** [New Thread 0x7f8503695700 (LWP 20012)] Program received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () #1 0x00007f84f671281e in

I have tried to define a domain or using virt-install both failed. Could some one give me the correct command to do this? I used: virt-install --nographics --paravirt --os-type=solaris --os-variant=opensolaris --ram 1024 --name cam-host --disk path=/dev/dsk/c0t600A0B800049E902000008EB4A9CE744d0p0,driver=phy -l /export/media_images/sol-nv-b121-x86-dvd.iso thx, florian