search for: 312b

...hr-20100228-000000CST received 271KB stream in 1 seconds (271KB/sec) sending from @bup-4hr-20100228-000000CST to zp1/lydy at bup-4hr-20100228-040000CST receiving incremental stream of zp1/lydy at bup-monthly-20100222-210000CST into bup-r\ uin/fsfs/zp1/lydy at bup-monthly-20100222-210000CST received 312B stream in 1 seconds (312B/sec) receiving incremental stream of zp1/lydy at bup-daily-20100222-210000CST into bup-rui\ n/fsfs/zp1/lydy at bup-daily-20100222-210000CST sending from @bup-4hr-20100228-040000CST to zp1/lydy at bup-4hr-20100228-080000CST received 312B stream in 1 seconds (312B/sec) recei...

...t 380r 0: valnos 0 1 3 1: valnos 2 In this particular case, I believe that it is the greedy allocator that is creating the multiple components in the %vreg77 live interval. If you look at the attached debug dump file, just after the greedy allocator runs, the segment of %vreg77 from the def at 312B to the use at 380B seems to be separable from the other segments. The reason the above verification failure is not hit at that point seems to be related to the FIXME in the following snippet from ConnectedVNInfoEqClasses::Classify(): // Normal value defined by an instruction. Check for...

...lnos 0 1 3 > 1: valnos 2 > > In this particular case, I believe that it is the greedy allocator that is creating the multiple components in the %vreg77 live interval. If you look at the attached debug dump file, just after the greedy allocator runs, the segment of %vreg77 from the def at 312B to the use at 380B seems to be separable from the other segments. The reason the above verification failure is not hit at that point seems to be related to the FIXME in the following snippet from ConnectedVNInfoEqClasses::Classify(): That dump seems to be well before greedy runs, isn't it? At...

...>> 1: valnos 2 >> >> In this particular case, I believe that it is the greedy allocator that is creating the multiple components in the %vreg77 live interval. If you look at the attached debug dump file, just after the greedy allocator runs, the segment of %vreg77 from the def at 312B to the use at 380B seems to be separable from the other segments. The reason the above verification failure is not hit at that point seems to be related to the FIXME in the following snippet from ConnectedVNInfoEqClasses::Classify(): > That dump seems to be well before greedy runs, isn't it...

...1: valnos 2 >>> >>> In this particular case, I believe that it is the greedy allocator that is creating the multiple components in the %vreg77 live interval. If you look at the attached debug dump file, just after the greedy allocator runs, the segment of %vreg77 from the def at 312B to the use at 380B seems to be separable from the other segments. The reason the above verification failure is not hit at that point seems to be related to the FIXME in the following snippet from ConnectedVNInfoEqClasses::Classify(): >> That dump seems to be well before greedy runs, isn'...

...e that it is the greedy allocator >>>> that is creating the multiple components in the %vreg77 live >>>> interval.  If you look at the attached debug dump file, just after >>>> the greedy allocator runs, the segment of %vreg77 from the def at >>>> 312B to the use at 380B seems to be separable from the other >>>> segments.  The reason the above verification failure is not hit at >>>> that point seems to be related to the FIXME in the following snippet >>>> from ConnectedVNInfoEqClasses::Classify(): >>&g...

..., TCGETS, {B38400 opost isig icanon echo ...}) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0 write(4, "\n", 1) = 1 close(4) = 0 write(3, "X=\340\0261\26\243\373\355<\305duV _b\320+\312B\353\253"..., 80) = 80 select(4, [3], NULL, NULL, NULL) = 1 (in [3]) read(3, "Hp\226B\223\363\205\267\267\337\315\5\5`wZ.\223\237\25"..., 8192) = 32 dup(0) = 4 dup(1) = 5 dup(2) =...

...>>>> >>>>> In this particular case, I believe that it is the greedy allocator that is creating the multiple components in the %vreg77 live interval. If you look at the attached debug dump file, just after the greedy allocator runs, the segment of %vreg77 from the def at 312B to the use at 380B seems to be separable from the other segments. The reason the above verification failure is not hit at that point seems to be related to the FIXME in the following snippet from ConnectedVNInfoEqClasses::Classify(): >>>> That dump seems to be well before greedy runs,...

...215\266\346+sV\356\223+3\375\355^r\267o\320b I\22"..., 1024) = 1024 write(5, "\372\360S$\365${y!]\3360\17\21\376\257\360\365g\2753XW"..., 1024) = 1024 write(5, "\265\344\216D\344\250e\346\17w9\255/o\253_\246\211\330"..., 1024) = 1024 write(5, "\324\375\242\235e\307\335\312B\334\247\265O^\21!?\221\257"..., 1024) = 1024 write(5, "\240{{l*\r\325H\365\224\21E(x\316\244\322\241\203\33\336"..., 1017) = 1017 select(5, [4], [], NULL, {60, 0}) = 1 (in [4], left {60, 0}) read(4, "g!\230\315T,\224\247iu\356[\37\220\373\t\37R\201\275{h"..., 8184) =...

...\223+3\375\355^r\267o\320b = I\22"..., 1024) =3D 1024 write(5, = "\372\360S$\365${y!]\3360\17\21\376\257\360\365g\2753XW"..., 1024) =3D = 1024 write(5, = "\265\344\216D\344\250e\346\17w9\255/o\253_\246\211\330"..., 1024) =3D = 1024 write(5, = "\324\375\242\235e\307\335\312B\334\247\265O^\21!?\221\257"..., 1024) = =3D 1024 write(5, = "\240{{l*\r\325H\365\224\21E(x\316\244\322\241\203\33\336"..., 1017) =3D = 1017 select(5, [4], [], NULL, {60, 0}) =3D 1 (in [4], left {60, 0}) read(4, "g!\230\315T,\224\247iu\356[\37\220\373\t\37R\201\275{h"....

...\213\f\334\203s\223"..., 80}], 1) = 80 epoll_wait(9, {{EPOLLIN, {u32=1836735552, u64=140507396856896}}}, 1, 30000) = 1 readv(44, [{"\5\0\0\3\20\0\0\0P\0", 10}], 1) = 10 readv(44, [{"\20\0\274])\1\26\0\0\0\0\0\24\0008\3412\232u\322\322\253\245I\10k\344\312\312B\22\307"..., 70}], 1) = 70 gettimeofday({1399964809, 86492}, NULL) = 0 time(NULL) = 1399964809 time(NULL) = 1399964809 time(NULL) = 1399964809 time(NULL) =...

...430: 6e67 6564 3106 0404 3338 3630 3021 0409 nged1...38600!.. 0x0440: 6c61 7374 4c6f 676f 6e31 1404 1231 3331 lastLogon1...131 0x0450: 3234 3231 3235 3230 3939 3133 3936 3030 2421252099139600 0x0460: 4004 1164 6973 7469 6e67 7569 7368 6564 @..distinguished 0x0470: 4e61 6d65 312b 0429 434e 3d75 7365 7232 Name1+.)CN=user2 0x0480: 2c43 4e3d 5573 6572 732c 4443 3d61 642c ,CN=Users,DC=ad, 0x0490: 4443 3d65 7861 6d70 6c65 2c44 433d 6e65 DC=example,DC=ne 0x04a0: 7430 3102 0106 6507 0a01 0004 0004 00a0 t01...e......... 0x04b0: 2330 2104 1631 2e32 2e38 3430...