Re: [Valgrind-users] core dump improvements - fix order of threads
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? It is not clear to me what is the above. I suppose that info threads does not work on a core dump, and so reports it cannot find new threads. Philippe -- 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] core dump improvements - fix order of threads
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
[Valgrind-users] core dump improvements - fix order of threads
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.
For exactly this problem I have two possible solutions:
A. Change the loop over all threads to be reversed:
- for(i = 1; i VG_N_THREADS; i++) {
+ for(i = VG_N_THREADS - 1; i = 1 ; i--) {
B. Change the function add_note (or related notes processing code), to
output the notes in the order add_note is called, and not backward.
I wonder which approach is better, but I tend to approach B, as then the
code creates the notes in the order they appear in the final core file.
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] core dump improvements - fix order of threads
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 ?
For exactly this problem I have two possible solutions:
A. Change the loop over all threads to be reversed:
- for(i = 1; i VG_N_THREADS; i++) {
+ for(i = VG_N_THREADS - 1; i = 1 ; i--) {
B. Change the function add_note (or related notes processing code), to
output the notes in the order add_note is called, and not backward.
I wonder which approach is better, but I tend to approach B, as then
the code creates the notes in the order they appear in the final core
file.
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
--
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
