Thanks for your reply. I am happy to report that adding
--vex-iropt-register-updates=allregs-at-mem-access
option to callgrind worked for me and I am able to run it without any
problems. I think the issue was that JVM generates a lot of SIGSEGV signals
during it's "normal" course of operation and valgrind did not like that. I
have same issue with gdb where I have to handle those signals while
debugging.
Thanks again!
-Eqbal
On Tue, Aug 2, 2016 at 10:16 PM, Julian Seward <jsew...@acm.org> wrote:
> On 02/08/16 22:30, Eqbal wrote:
>
> >> valgrind -v --tool=callgrind --dump-instr=yes --trace-jump=yes
> >> --trace-children=yes --smc-check=all --collect-jumps=yes
> >> --simulate-cache=yes ./example
>
> Try adding --px-default=allregs-at-mem-access. If that doesn't help
> then try --px-default=allregs-at-each-insn. You'll take a big performance
> hit though.
>
> It might also be -- looking at the other info in the report -- that this is
> some kind of security sandbox problem, in which the process is denied
> permission to proceed further at some point, because it is Valgrind that
> is running, not the JVM. In which case the above flags won't help.
>
> J
>
>
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
