Re: [Valgrind-users] core dump improvements - fix order of threads

2012-04-28 Thread Matthias Schwarzott
On 27.04.2012 19:18, Philippe Waroquiers wrote:
 On Fri, 2012-04-27 at 11:49 +0200, Matthias Schwarzott wrote:
 Hi there!

 Comparing the output from gdb attached to valgrind gdbserver and the
 core file valgrind creates, the thread order is inverted.
 As I have more minor issues with gdb and valgrind core files, I do not
 known if this is always the case.
 I do not think that there is a consistent order (inverted or not)
 between the list of gdbserver threads reported to gdb
 and the list of threads in the VG thread array.
 The valgrind gdbserver maintains a linked list of threads
 derived from new threads appearing in the array or old threads
 that disappeared.
 I believe (not checked) that if you have:
 create thread a
 create thread b
 create thread c
 delete thread b
 create thread d
 that the VG array will contain a d b
 while the gdbserver linked list will contain d b a.

 If the above is correct, then the changes below will not guarantee
 the order is the same.
 Also, not too sure what gdb does with the list of threads it receives
 from the gdbserver (maybe gdb sorts them ?).

 Just to understand, why do you need to make the link between
 the V core thread list and the V gdbserver thread list ?
 Is it because you obtain a core dump, that you then try to
 understand with V gdbserver in another run ?
I wanted to make the order of threads consistent between all 4 possible 
ways:
1. gdb application
2. core dump of application
3. valgrind gdbserver application
4. valgrind core file of application

Maybe there is some other piece missing (see my posting before this topic).
My gdb is not sure about the threads:
(gdb) info threads
Cannot find new threads: generic error

But:
(gdb) thread apply 1-2 bt

Thread 1 (LWP 6):
#0  0x003e93a329b5 in raise () from /lib64/libc.so.6
#1  0x003e93a33d5a in abort () from /lib64/libc.so.6
#2  0x0040082b in main ()

Thread 2 (LWP 7):
#0  0x003e93ab56dd in nanosleep () from /lib64/libc.so.6
#1  0x003e93ab5589 in sleep () from /lib64/libc.so.6
#2  0x0040079a in th ()
#3  0x003e94607006 in start_thread () from /lib64/libpthread.so.0
#4  0x003e93ae780d in clone () from /lib64/libc.so.6

But I have no idea how to getinto this problem.
Is it necessary to debug or trace gdb+bfd for that?

Regards
Matthias


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users


Re: [Valgrind-users] can't start any application on OS X 10.7.3

2012-04-28 Thread Matt Broadstone
On Fri, Apr 27, 2012 at 6:42 PM, Julian Seward jsew...@acm.org wrote:
 On Friday, April 27, 2012, Matt Broadstone wrote:
 On Fri, Apr 27, 2012 at 10:58 AM, Julian Seward jsew...@acm.org wrote:
  * change the line
     MACX_(__NR___pthread_sigmask,       __pthread_sigmask),
    to read
     MACX_(__NR___pthread_sigmask,       __pthread_sigmask),
 
  Oops.  I mean, change it to
 
    MACXY(__NR___pthread_sigmask,       __pthread_sigmask),
 
  J

 Hmm, well I added that (I had to provide an empty POST for
 __pthread_sigmask to get it working, not sure if thats kosher, it
 looked like it should be), but we're still failing.

 My analysis was wrong.  It's unrelated to __pthread_sigmask;
 the program has already decided to abort before that point.

 Seems like a permissions problem of some kind (setuid problem,
 I'd guess).  Putting sudo in front of my valgrind invokation
 for textedit makes it run successfully.  Does the same trick
 work for you?

 J

Yep, this works for me.

Matt

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users