On Wed, 2012-07-18 at 01:22 +, Anup wrote:
--4562:1:gdbsrv getpkt (C14); [no ack]
--4562:1:gdbsrv set_desired_inferior use_general 0 found 0x402514BE0 tid 1
lwpid 4562
--4562:1:gdbsrv resume_info thread 4562 leave_stopped 0 step 0 sig 17
stepping
0
--4562:1:gdbsrv stop pc
On 18/07/12 10:03, daniel.jan...@edgeware.tv wrote:
Thanks, running ulimit -n 10 seems to fix my problem. It's strange
though since the program under test sets its own limit RLIMIT_NOFILE with
setrlimit().
Does it check the return value? I suspect it doesn't ;-)
To explain, because
unsub
Best Regards
Rahul Singh
Continental Automotive Singapore Pte Ltd
3 Kallang Sector, #04-05
Singapore 349278
DID : (65) 6848 6548
Email:rahul.si...@continental-corporation.com
http://www.continental-corporation.com
From: Tom Hughes t...@compton.nu
To: daniel.jan...@edgeware.tv
Cc:
Am 13.07.2012 um 13:55 schrieb Julian Seward:
So it's precisely commit r12466 which makes valgrind fail on at least Lion.
Commit diff: http://markmail.org/thread/gyxvhml2ungpxyad
Thanks for the bisecting. If you use ToT with r12466 backed out, does it
work? Can you try with both
On Wednesday, July 18, 2012, Nikolas Zimmermann wrote:
Thanks for the bisecting. If you use ToT with r12466 backed out, does it
work? Can you try with both --tool=none and --tool=memcheck ?
I'll try it as soon as trunk builds again on Mac OSX 10.7:
m_debuginfo/readmacho.c: In function
Am 18.07.2012 um 12:48 schrieb Julian Seward:
Fixed, r12754. Urr. We should have noticed that earlier.
Thanks. I've updated and backed out the problematic revision, and now valgrind
works again as expected.
So reverting indeed fixes my issues. (Jacob, can you confirm this by building
