search for: ptrptr

...: > Hi Piotr, > > On April 6, 2017 at 2:36:53 AM, Piotr Padlewski > (piotr.padlewski at gmail.com) wrote: > > I disagree, I find it different than the patch you mentioned. We don't > have > > any problems with code like this: > > > > ptr = load i8*, i8** %ptrptr, !dereferenceable !{i64 8} > > if (false) { > > > > // ptr is not actually dereferenceable, even the load above has UB > > // (since the metadata is "wrong"), but it is never executed so all is > > well. > > int val = *ptr; > > } > > I was n...

...rry for being *this* annoying, but I'm not on board with this. :) > > I think this will run into the same dead-code-can-affect-behavior > issue discussed in https://reviews.llvm.org/D20116. > > Specifically, if your program is: > > if (false) { > ptr = load i8*, i8** %ptrptr, !dereferenceable !{i64 8, !"GlobalProperty} > // ptr is not actually dereferenceable, even the load above has UB > // (since the metadata is "wrong"), but it is never executed so all is > well. > int val = *ptr; > } > > then you could transform it to >...

...org> wrote: > Hi Piotr, > > On April 6, 2017 at 9:28:58 AM, Piotr Padlewski > (piotr.padlewski at gmail.com) wrote: >> Hi Sanjoy, >> My point is that this it is exactly the same way as normal !dereferenceable >> introduces UB. >> >> ptr = load i8*, i8** %ptrptr, !dereferenceable !{i64 8} >> if (false) { >> int val = *ptr; >> } > > These are two different things. > > In the above example, your original program executes a load that was > supposed to produce a dereferenceable value, but it did not. This > means the origin...

...r(virErrorPtr err) { if (err == NULL) return; VIR_FREE(err->message); VIR_FREE(err->str1); VIR_FREE(err->str2); VIR_FREE(err->str3); memset(err, 0, sizeof(virError)); } # define VIR_FREE(ptr) virFree(1 ? (void *) &(ptr) : (ptr)) void virFree(void *ptrptr) { int save_errno = errno; free(*(void**)ptrptr); *(void**)ptrptr = NULL; errno = save_errno; } when my daemon link with jemalloc must core，but if i use glibc to manage memory ,then it work fine, why ?

2017-04-01 15:59 GMT+02:00 Piotr Padlewski <piotr.padlewski at gmail.com>: > > > 2017-03-31 23:20 GMT+02:00 Sanjoy Das <sanjoy at playingwithpointers.com>: > >> Hi Piotr, >> >> On March 31, 2017 at 1:07:12 PM, Piotr Padlewski >> (piotr.padlewski at gmail.com) wrote: >> > [snip] >> > Do I understand it correctly, that it is legal to

Hey! It seems that if I close a connection while a domain event callback is in progress, I can easily have a crash. Here is a backtrace: #v+ #0 virFree (ptrptr=0x0) at ../../../src/util/viralloc.c:582 save_errno = <optimized out> #1 0x00007fc8328a4ad2 in virObjectEventCallbackListPurgeMarked (cbList=0xadfc30) at ../../../src/conf/object_event.c:282 freecb = <optimized out> n = 0 #2 virObjectEventStateFlush (state=0xaf...

...gt; test/DebugInfo/implicit_pointer_mem2reg.c >> ------------------------------------------------ >> # cat multilevel_pointer.c >> static const char *b = "opq"; >> volatile int v; >> int main() { >> int var1 = 4; >> int *ptr1; >> int **ptrptr1; >> >> v++; >> ptr1 = &var1; >> ptrptr1 = &ptr1; >> v++; >> >> return *ptr1 + **ptrptr1 - 5; >> } >> ------------------------------------------------ >> With the the current set of patches it produces DWARF as below >...

Hi, I'm having problems with libvirt crashing after a couple hours when a specific domain monitoring program is running. I have pasted below the following: 1. libvirt version 2. qemu-kvm version 3. OS version 4. Kernel version 5. libvirt status post-crash 6. libvirtd.log (info level dump around crash; too long to post everything so just the beginning and end. UTC) 7. custom.log (on what

Let me try to summarize the implementation first. At the moment, there are two branches. 1. When an existing variable is optimized out and that variable is used to get the de-refereced value, pointed to by another pointer/reference variable. Such cases are being addressed using Dwarf expression DW_OP_implicit_pointer as de-referenced value of a pointer can be seen implicitly (using another

(I'm still pretty concerned that there are IR changes going in for a feature that seems incomplete and more invasive than really seems justified to me - though I admit I'm clearly not paying enough attention to this feature to have a nuanced/fully informed opinion & so maybe I just need to step back from all of this - but given the addition of new intrinsics, it seems like there should