search for: watchpoint

On Thu, Jun 26, 2014 at 3:39 PM, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote: > The main motivation for turning it off is that no known consumer (debugger) > took advantage of it. > > Turning it on does more than slightly increase the object file size, it can > cause the same source line to be listed multiple times in the .debug_line > table (with different

Hello, everyone I am a newbie of DTrace and OpenSolaris. Just wondering is it possible to trace every memory read/write of a specific process given the pid? Basically speaking, I want to record the virtual addresses being accessed by the process, using which I will try to do some online analysis. If DTrace does not support this type of instrumentation, will other tools in OpenSolaris help me

...+ lockdep_hardirqs_on(CALLER_ADDR0); + } +#endif + raw_local_irq_restore(irq_state->flags); + } #ifdef CONFIG_TRACE_IRQFLAGS - task->irqtrace = task->kcsan_save_irqtrace; + task->irqtrace = irq_state->irqtrace; #endif } @@ -350,11 +383,13 @@ static noinline void kcsan_found_watchpoint(const volatile void *ptr, flags = user_access_save(); if (consumed) { - kcsan_save_irqtrace(current); + struct kcsan_irq_state irqstate; + + kcsan_save_irqtrace(&irqstate); kcsan_report(ptr, size, type, KCSAN_VALUE_CHANGE_MAYBE, KCSAN_REPORT_CONSUMED_WATCHPOINT, wa...

...> Good: > Breakpoint 1, dcrypt_initialize (backend=0x555555587c02 "openssl", > set=0x0, error_r=0x0) at dcrypt.c:15 > 15 if (dcrypt_vfs != NULL) { > $1 = (struct dcrypt_vfs *) 0x0 > $2 = (struct dcrypt_vfs **) 0x555555796370 <dcrypt_vfs> > Hardware watchpoint 3: dcrypt_vfs > Breakpoint 2, dcrypt_set_vfs (vfs=0x7ffff7835020 <dcrypt_openssl_vfs>) > at dcrypt.c:56 > 56 dcrypt_vfs = vfs; > $3 = (struct dcrypt_vfs *) 0x0 > $4 = (struct dcrypt_vfs **) 0x555555796370 <dcrypt_vfs> > Hardware watchpoint 3: dcrypt_vfs &...

I'm using bleeding-edge R-devel, so maybe my build is weird. Can anyone else reproduce this? View() seems to crash on just about anything. View(1:3) *** stack smashing detected ***: terminated Aborted (core dumped) If I debug(View) I get to the last line of code with nothing obviously looking pathological: Browse[1]> debug: invisible(.External2(C_dataviewer, x, title))

(not sure whether this is better for R-devel or R-help ...) I am currently trying to debug someone else's package (they're not available at the moment, and I would like it to work *now*), which among other things allocates memory for a persistent buffer that gets used by various functions. The first symptoms of a problem were that some things just didn't work under Windows but were

(Please keep me CC'd as I'm not subscribed to the list) I'd like to request that folks running RELENG_8 (and RELENG_9, though I do not use it) please check the behaviour of their terminal after each of following commands are run (check terminal after each command): top -a (press "q" after 1 screen refresh) top -b If you find that your input characters in your shell

...e110, V1=0xd1c420, V2=0xd3b168) at /nfs/llvm/src/llvm/lib/Transforms/Scalar/ PredicateSimplifier.cpp:1612 1612 IG.node(NI->To)->update(n1, reversePredicate(NI- >LV), Top); (gdb) p NI $28 = ((anonymous namespace)::InequalityGraph::Edge *) 0xd56340 (gdb) watch *0xd56340 Watchpoint 6: *13984576 (gdb) c Continuing. Watchpoint 6: *13984576 Old value = 2 New value = 1515870810 0x00000008013e1e84 in memset () from /lib/libc.so.7 (gdb) bt #0 0x00000008013e1e84 in memset () from /lib/libc.so.7 #1 0x000000080136ecd1 in malloc_usable_size () from /lib/libc.so.7 #2 0x000000080136e...

...e; done None of them seem to be suspects... Trussing all of the procs does''t look like an option as there are dynamically forked procs... Wish to know how can I find the process or the entity which is modifying the timestamp memory using tools like mdb/dtrace... something like setting a watchpoint on this timestamp memory at the kernel debug level and watching who changed it etc., This message posted from opensolaris.org

...ing google is that it's a potential problem with the interaction between selinux & auditd, but i haven't found a solution. two questions: 1. anyone know what the problem is? (that or my next step in diagnosing it) 2. if i can't solve it, is there an alternative method for adding watchpoints to directories such that i can be notified of WRITE events for files in that directory (and preferably for all of it's subdirectories)? My kernel version is 2.6.18 (full info below). The audit version is audit.x86_64 0:1.7.13-2.el5 thanks --tom Name : kernel Arch : x...

Dear R-devel, Last week I got several responses to my question about debugging segfaults in my code (original post below). After I changed the S_alloc() calls to Calloc()/Free(), the symptom was gone, but I was told to keep looking. So I did: o Switched to Calloc/Free. Electric Fence did not find any problem. o Put assert(index < bound); assert(index >=0); everywhere in the C routine

...at /nfs/llvm/src/llvm/lib/Transforms/Scalar/ > PredicateSimplifier.cpp:1612 > 1612 IG.node(NI->To)->update(n1, reversePredicate(NI- > >LV), Top); > (gdb) p NI > $28 = ((anonymous namespace)::InequalityGraph::Edge *) 0xd56340 > (gdb) watch *0xd56340 > Watchpoint 6: *13984576 > (gdb) c > Continuing. > Watchpoint 6: *13984576 > > Old value = 2 > New value = 1515870810 > 0x00000008013e1e84 in memset () from /lib/libc.so.7 > (gdb) bt > #0 0x00000008013e1e84 in memset () from /lib/libc.so.7 > #1 0x000000080136ecd1 in malloc_usab...

Hi Olly, I updated my local repo and built it again, but still getting the error. I took a look at python3/test-suite.log file, but I could not locate the source of test failure. Please find attached the log file with this email. I am available on IRC(nick : ankit_agrawal) if that seems a convenient medium for you to help me out with this issue. Thanks. Regards, Ankit Agrawal,

On Wed, Aug 05, 2020 at 03:59:40PM +0200, Marco Elver wrote: > On Wed, Aug 05, 2020 at 03:42PM +0200, peterz at infradead.org wrote: > > Shouldn't we __always_inline those? They're going to be really small. > > I can send a v2, and you can choose. For reference, though: > > ffffffff86271ee0 <arch_local_save_flags>: > ffffffff86271ee0: 0f 1f 44 00 00

On Wed, Aug 05, 2020 at 03:59:40PM +0200, Marco Elver wrote: > On Wed, Aug 05, 2020 at 03:42PM +0200, peterz at infradead.org wrote: > > Shouldn't we __always_inline those? They're going to be really small. > > I can send a v2, and you can choose. For reference, though: > > ffffffff86271ee0 <arch_local_save_flags>: > ffffffff86271ee0: 0f 1f 44 00 00

.... Starting again with a breakpoint at mapply.c:46, and watching the memory location of length_op, once assigned, for a write at the address of length_op (gdb) b mapply.c:46 (gdb) r ... (gdb) p length_op $11 = (SEXP) 0x4d772a0 (gdb) watch *0x4d772a0 (gdb) c leads to (gdb) c Continuing. Hardware watchpoint 4: *0x4d772a0 Old value = 8 New value = 0 Rf_allocSExp (t=<optimized out>) at /home/biocbuild/src/R-3.0.r62077/src/main/memory.c:2056 2056 TYPEOF(s) = t; which is R writing a new SEXP to the length_op location, as though this location had been garbage collected. Asking for R_P...

Hello, I'm currently developing a tool based on LLVM to understand how the LLVM IR changes after optimization passes are run. Today it's a tedious but automatic process at a function level in my language, where I first dump the IR before running any passes, and then do it for the 10 or so passes I care about one-at-a-time to understand which pass affected the change. There are two

On May 25, 2008, at 1:39 PM, Marcel Moolenaar wrote: > On May 25, 2008, at 12:58 AM, Bill Wendling wrote: > >> Could you try this (massively hacky) patch out to see if it fixes >> your >> problem? >> >> > Alas, it didn't fix the problem: > Crumbs. I think that the analysis I told you before wasn't fully correct. I think I mentioned something

...4486d <_ZL23__gxx_exception_cleanup19_Unwind_Reason_CodeP17_Unwind_Exception+61>: add %r8b,(%rax) 0x102244870 <__cxa_throw>: jmpq 0xffd27000 0x102244875 <__cxa_throw+5>: or (%rax),%eax 0x102244877 <__cxa_throw+7>: push %rbx (gdb) (gdb) watch *0x102244870 Hardware watchpoint 2: *4330899568 (gdb) r Old value = -788165304 New value = -1373139991 0x0000000100016203 in __asan_mach_override_ptr_custom () (gdb) bt #0 0x0000000100016203 in __asan_mach_override_ptr_custom () #1 0x0000000100015a9e in __interception::OverrideFunction () #2 0x00007fff5fc13378 in ImageLoaderMa...

...gc() explicitly, > not call any external code - e.g. the jobs, etc) - any time the example > is reduced but still triggers the errors, the reasoning is made easier. > Once you have a repeatable situation in a build with reliable debug > symbols, debugging is easier too, e.g. sometimes a watchpoint helps to > find memory corruption. Please feel free to ask more when you have more > information/updates. If this ends up being a bug in R, please report > (and with a reproducible example, if it is not obvious from the source > code). > > Best > Tomas > > > On 8/2/19...