search for: 48b8

...8bcb59-f25b-4edc-a525-e92272f54391 [2011-04-20 12:55:06.945027] I [glusterd-utils.c:2062:glusterd_friend_find_by_uuid] glusterd: Friend found.. state: Peer in Cluster [2011-04-20 12:55:06.945124] I [glusterd3_1-mops.c:395:glusterd3_1_cluster_lock_cbk] glusterd: Received ACC from uuid: e9a3d2b9-1292-48b8-9029-aedbe7fa837a [2011-04-20 12:55:06.945144] I [glusterd-utils.c:2062:glusterd_friend_find_by_uuid] glusterd: Friend found.. state: Peer in Cluster [2011-04-20 12:55:06.945166] I [glusterd-utils.c:726:glusterd_volume_brickinfo_get_by_brick] : brick: bebr0lbr6:/var/lib/gluster [2011-04-20 12:55:06...

...4BA4-AFDE-F43E9BA29309} drwxrwx---+ 5 root BUILTIN\administrators 4096 Set 17 2015 {D0A148C8-E2D7-4AC7-97C2-AA0AB00C7EC3} drwxrwx---+ 5 root BUILTIN\administrators 4096 Out 9 2015 {D95AC996-7CAA-4F08-991D-6EBBD409496A} drwxrwx---+ 5 root BUILTIN\administrators 4096 Set 16 2015 {DC037D0D-72CE-48B8-9012-FE493E2BF702} drwxrwx---+ 5 root BUILTIN\administrators 4096 Set 16 2015 {E8224A95-DEF9-4E87-B4E0-7E3F901D54A5} drwxrwx---+ 5 root BUILTIN\administrators 4096 Set 16 2015 {EA2E9E87-27B1-4971-87CC-489E2B099020} drwxrwx---+ 5 root BUILTIN\administrators 4096 Set 16 2015 {FA919892-77CE-4426...

Hello! samba -b | grep STATEDIR STATEDIR: /opt/samba/var/locks I commented at line idmap_ldb:use rfc2307 = yes in my smb.conf, error is diferent now samba-tool ntacl sysvolreset open: error=2 (No such file or directory) ERROR(runtime): uncaught exception - (-1073741823, 'Undetermined error') File "/opt/samba/lib/python2.7/site-packages/samba/netcmd/__init__.py",

running ubuntu 10.04 LTS with wine 1.1.44 > fixme:msi:MsiGetMode unimplemented run mode: 0 > fixme:msi:ACTION_ValidateProductID partial stub: template L"77718<````=````=````=````=`````>@@@@@" key L"JWFMGDGVMWKPVD39RX6PW2GQY" > err:module:import_dll Library sqdedev.DLL (which is needed by L"C:\\users\\leecarey\\Temp\\msi8258.tmp") not found >

...ll attempt to decode the "garbage" in the instruction stream, even if there is a jump over it? (IIRC they will decode ahead of the PC and hiccup (but not fault) on garbage). Maybe it would be better to steganographically encode the value inside the instruction stream? On x86 you could use 48b8<imm64> which only has 2 bytes overhead for an i64 (putting a move like that, which moves into a caller-saved register on entry, would effectively be a noop). This is some pretty gnarly target-dependent stuff which seems like it would best be hidden in the backend (e.g. architectures that have...

...the "garbage" in > the instruction stream, even if there is a jump over it? (IIRC they will > decode ahead of the PC and hiccup (but not fault) on garbage). Maybe it > would be better to steganographically encode the value inside the > instruction stream? On x86 you could use 48b8<imm64> which only has 2 bytes > overhead for an i64 (putting a move like that, which moves into a > caller-saved register on entry, would effectively be a noop). On the contrary, I think this is a good argument for allowing (not forcing) frontends to encode the prefix data as they plea...

On 6/17/2016 12:32 PM, Carlos A. P. Cunha wrote: > Hello! > Yes path is correct, so that when you run the reset Sysol he saw > changing permissions of various files (as mentioned) after a time > (over 10 minutes) the error occurred. > > dc 1 and dc 2: > > /usr/local/samba/etc/smb.conf > > [sysvol] > path = /opt/samba/var/locks/sysvol > > >

Hi, I would like to propose that we introduce a mechanism in IR to allow arbitrary data to be stashed before a function body. The purpose of this would be to allow additional data about a function to be looked up via a function pointer. Two use cases come to mind: 1) We'd like to be able to use UBSan to check that the type of the function pointer of an indirect function call matches the

...> in > > the instruction stream, even if there is a jump over it? (IIRC they will > > decode ahead of the PC and hiccup (but not fault) on garbage). Maybe it > > would be better to steganographically encode the value inside the > > instruction stream? On x86 you could use 48b8<imm64> which only has 2 > bytes > > overhead for an i64 (putting a move like that, which moves into a > > caller-saved register on entry, would effectively be a noop). > > On the contrary, I think this is a good argument for allowing > (not forcing) frontends to encode...