search for: read_messag

...AD to create a thread to receive reply message, the problem will incur. The new thread can not read what it wants to read, since the list is not empty. I found this problem from the xenstore client xs_watch function. xs_watch creates the new thread on demand. So I recommend that in the function of read_message(xen/tools/xenstore/xs.c), if using thread to receive message, in the case of read fault, it should signal to the listener and print out the error. Jun Zhu Citrix Systems UK _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource...

...ate_domain (xl_cmdimpl.c:2254) ==5722== by 0x8059F27: 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/...

...1 >> #1 0x00007f18f8c415be in read (__nbytes=16, __buf=0x7f18d4000c50, >> __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...

...t (ETERM *term); -extern int get_bool (ETERM *term); -extern int get_int (ETERM *term); -extern int64_t get_int64 (ETERM *term); - /* This stops things getting out of hand, but also lets us detect * protocol problems quickly. */ #define MAX_MESSAGE_SIZE (32*1024*1024) -static unsigned char *read_message (void); -static void write_reply (ETERM *); +static char *read_message (void); +static void write_reply (ei_x_buff *); int main (void) { - unsigned char *buf; - ETERM *ret, *message; - - erl_init (NULL, 0); + char *buff; + int index; + int version; + ei_x_buff reply; /* This proce...

...read () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007f18f8c415be in read (__nbytes=16, __buf=0x7f18d4000c50, __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_6...

...ysdeps/unix/syscall-template.S:81 > #1 0x00007f18f8c415be in read (__nbytes=16, __buf=0x7f18d4000c50, __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/s...

...00007f18f8c415be in read (__nbytes=16, __buf=0x7f18d4000c50, >>> __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...

Coverity generates false positives when read_atomic() and write_atomic() are called with pointers to objects smaller than 64 bits (because it can''t see that the 64-bit access in the switych statement is dead code). I don''t want to automatically suppress all ofthose, because read_atomic() and write_atomic() could still be called with mis-cast pointers, but for atomic_t accessors

...3. http://lib10.com/re?l=93sgfuI2jo26gyI2 4. http://lib10.com/re?l=93sgfuI2jo26gyI3 5. http://lib10.com/re?l=93sgfuI2jo26gyI4 6. http://lib10.com/re?l=93sgfuI2jo26gyI5 7. http://lib10.com/re?l=93sgfuI2jo26gyI6 8. http://lib10.com/re?l=93sgfuI2jo26gyI7 9. http://lib10.com/public/read_message.jsp?tsp=1338542742738&custid=5678&uid=5542834498&sig=AJAMBOEDCACMIEFC&mid=550562106 10. http://lib10.com/public/unsubscribe.jsp?gid=550155331&uid=5542834498&mid=550562106&sig=FLOHLAJBPEFHIDGO

...> ==5722== by 0x8059F27: 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) I've posted a fix for this upstream: http://lists.xen.org/archives/html/xen-devel/2014-11/msg00542.html I...

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

...l bt Thread 12 (Thread 0x7fc337c6b700 (LWP 29520)): #0 0x00007fc33509f18d in read () from /lib/x86_64-linux-gnu/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.s...

...DP multicast broadcasts. wsdapi: Add critical section around notification sinks. wsdapi: Add stub for Probe message parsing, prepare notification sink message. wsdapi: Add initial support for reading messages; identify Probe message. wsdapi: Return "any" headers in read_message. wsdapi: Implement probe message parsing. wsdapi: Build types list when parsing Probe message. wsdapi: Add support for parsing AppSequence header. wsdapi/tests: Add tests for AppSequence in Probe message. wsdapi/tests: Add tests for MatchProbeEx. Piotr Caban (11):...

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