Re: [Valgrind-users] Failed to read a valid object file image from memory.
On 14.04.2015 21:24, Philippe Waroquiers wrote: On Tue, 2015-04-14 at 19:26 +0100, João M. S. Silva wrote: What you can further do is to use the memcheck monitor commands to examine the definedness of the variables used on the line where the error is detected. See manual for more info http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands Thanks, I didn't know about the monitor get_vbits command. However, it seems I'm not able to catch any uninitialized variable. I do not understand. The below error is an uninitialised value error. Why do you say you cannot catch the errors ? You just have to use monitor get_vbits at the time of the error to investigate more in depth where the error comes from, and if needed, relaunch the execution after having added some breakpoints earlier in the program flow, and again use get_vbits to try to understand where the uninit error comes from. I also get this kind of error in another library: ==17108== Use of uninitialised value of size 8 ==17108==at 0x60BDB6D: decode_rs_char (decode_rs.h:118) ==17108==by 0x41D9B5: Code::decode(unsigned char*, int*, unsigned int, bool) (Code.cpp:114) ==17108==by 0x41E6D8: Code::extract(char*, char*, std::string, unsigned int) (Code.cpp:326) ==17108==by 0x4060E4: main (test.cpp:178) ==17108== Uninitialised value was created by a stack allocation ==17108==at 0x60BD480: decode_rs_char (decode_rs_char.c:15) And with vgdb I get this in gdb: Program received signal SIGTRAP, Trace/breakpoint trap. 0x060bdb6d in decode_rs_char (p=0x201aac50, data=0xffefff500 , eras_pos=0xffefff480, no_eras=22) at decode_rs.h:118 118 tmp = INDEX_OF[lambda[j - 1]]; Yes that is the way the valgrind gdbserver reports to gdb that there is an error that the user can look at. I tried the get_vbits command in variables p, data, eras_pos and no_eras. I had to manually find out the size of the corresponding variables, since some of them are pointers or structs with pointer fields. Yes, the monitor get_vbits only knows about address+length. So, you need to do something like (gdb) p myvar (gdb) p sizeof(myvar) and then use (gdb) monitor get_vbits address size to get the vbits. I defined a gdb-macro for this: define get_vbits printf # mon get_vbits 0x%lx 0x%lx\n , $arg0 , sizeof($arg0) eval mon get_vbits 0x%lx 0x%lx , $arg0 , sizeof($arg0) end Then I can run: (gdb) get_vbits i_Cond # mon get_vbits 0xffefff8bf 0x1 00 (gdb) For the case above, you should check the instruction triggering the error. (gdb) x/i $rip Then you know in what register to look for. with the complete disassembly you might be able to track down what it exactly was. Then look near the problematic instruction. (gdb) disassemble /m I think there was also some option to switch valgrind so that the definedness of registers can be checked: --vgdb-shadow-registers=yes Regards Matthias -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Memcheck does not report any error
On 29.09.2013 13:16, Damien R wrote:
Hi,
I am using valgrind 3.7.0 and with the following program, valgrind
reports no error.
#include iostream
struct Foo
{
void print()
{
std::cout foo std::endl;
}
};
int main()
{
Foo * foo = new Foo;
delete foo;
foo-print();
return 0;
}
Can someone explain why valgrind does not report any error?
Hi!
You call Foo::print() on a deleted instance of Foo, but this method does
not access any data from inside Foo and is no virtual method.
So nothing happens, that valgrind should complain about.
Regards
Matthias
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] [PATCH] Fix vgcore file to show the crashed thread
Hi there! I changed writing of vgcore to make it obvious which thread has crashed. This is done by moving the thread info for the crashing thread to be the first. See https://bugs.kde.org/show_bug.cgi?id=315199 If thread 5 crashed, gdb opening vgcore still shows thread 1 as active. After my change, thread 5 is the active one. Question: How to create a test for this? My naive idea: The test needs to run valgrind until the client app crashes, and then open vgcore in gdb to issue bt and check if this is the correct callstack. Regards Matthias -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] Show more callstacks for MemoryPool related errors
Hi there! As the new valgrind can show alloc and free callstack for use after free of normal heap memory I thought this should also work for memory pools. There are even more callstacks that are known. See https://bugs.kde.org/show_bug.cgi?id=322256 For the testcase clireq_nofill.c Before: ==26295== Invalid read of size 1 ==26295==at 0x8048780: main (clireq_nofill.c:23) ==26295== Address 0x4034028 is 0 bytes inside a recently re-allocated block of size 40 alloc'd ==26295==at 0x4009D98: malloc (vg_replace_malloc.c:270) ==26295==by 0x804860E: main (clireq_nofill.c:16) ==26295== After: ==26693== Invalid read of size 1 ==26693==at 0x8048780: main (clireq_nofill.c:23) ==26693== Address 0x4034028 is 0 bytes inside a recently re-allocated block of size 40 alloc'd ==26693==at 0x40093A1: malloc (vg_replace_malloc.c:291) ==26693==by 0x804860E: main (clireq_nofill.c:16) ==26693== inner block was freed at ==26693==at 0x804876B: main (clireq_nofill.c:22) ==26693== inner block was allocated at ==26693==at 0x80486E0: main (clireq_nofill.c:20) For this I only wonder about how to name the different callstacks. Regards Matthias -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] Time relation between errors in xml format and stdout/stderr
Hi, I am running a larger test-application under valgrind. It prints start and end of testcases to stderr. Using the text output I immediately see to which testcase an error belongs. Now is the point I want to get some numbers about valgrind errors extracted. For this xml is the type of output to use. I wonder if it is possible to get the errors xml-format and still know the relation to the stderr output. These are my thoughts: 1. Enable text and xml error output the same time. 2. Print a reference to the xml error-id onto stderr. 3. Using --xml=yes --xml-fd=2 and splitting it later (maybe add some prefix to these lines). What do you think about this? Regards Matthias -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] [PATCH] Improve errors for use-after-free on memory pools
On 12.02.2013 10:12, Paul Menzel wrote: Dear Matthias, I am new to Valgrind too. Reading the Mailing Lists and IRC Web page [1] there is also a developer list, where your patch might get more attention. Am Dienstag, den 12.02.2013, 07:13 +0100 schrieb Matthias Schwarzott: Currently the valgrind-message for use-after-free for a memory pool consists of the execution callstack and the callstack, where the superblock was allocated. To better diagnose it I wanted to get also the callstack of the place where MEMPOOL_FREE was called. Sounds like a nice idea to me. The attached patch uses the new fields added for use-after-free messages that show two callstacks. It is just a proof of concept. How could it be improved? Could you show a trace without and with your patch applied? testcase memcheck/test/clireq_nofill before: *s=0x5 after MEMPOOL_ALLOC ==21626== Invalid read of size 1 ==21626==at 0x400A52: main (clireq_nofill.c:23) ==21626== Address 0x4c58040 is 0 bytes inside a recently re-allocated block of size 40 alloc'd ==21626==at 0x4A091AD: malloc (vg_replace_malloc.c:270) ==21626==by 0x40091A: main (clireq_nofill.c:16) ==21626== *s=0x5 after MEMPOOL_FREE *s=0x5 after second MEMPOOL_ALLOC *s=0x5 after MALLOCLIKE_BLOCK ==21626== Invalid read of size 1 ==21626==at 0x400C9B: main (clireq_nofill.c:36) ==21626== Address 0x4c580b0 is 0 bytes inside a recently re-allocated block of size 40 alloc'd ==21626==at 0x4A091AD: malloc (vg_replace_malloc.c:270) ==21626==by 0x400B65: main (clireq_nofill.c:29) ==21626== *s=0x5 after FREELIKE_BLOCK after: *s=0x5 after MEMPOOL_ALLOC ==24145== Invalid read of size 1 ==24145==at 0x400A52: main (clireq_nofill.c:23) ==24145== Address 0x4c57040 is 0 bytes inside a recently re-allocated block of size 40 alloc'd ==24145==at 0x4A08C8F: malloc (vg_replace_malloc.c:270) ==24145==by 0x40091A: main (clireq_nofill.c:16) ==24145== block was re-alloced at ==24145==at 0x400A43: main (clireq_nofill.c:22) ==24145== *s=0x5 after MEMPOOL_FREE *s=0x5 after second MEMPOOL_ALLOC *s=0x5 after MALLOCLIKE_BLOCK ==24145== Invalid read of size 1 ==24145==at 0x400C9B: main (clireq_nofill.c:36) ==24145== Address 0x4c570b0 is 0 bytes inside a recently re-allocated block of size 40 alloc'd ==24145==at 0x4A08C8F: malloc (vg_replace_malloc.c:270) ==24145==by 0x400B65: main (clireq_nofill.c:29) ==24145== block was re-alloced at ==24145==at 0x400C8C: main (clireq_nofill.c:35) ==24145== *s=0x5 after FREELIKE_BLOCK *s=0x5 after second MALLOCLIKE_BLOCK I wonder if this will work in all cases. And maybe the text for the third callstack could be changed to block was freed at. I will create a bug ticket to track this. Regards Matthias -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] [PATCH] Improve errors for use-after-free on memory pools
Hi there!
Currently the valgrind-message for use-after-free for a memory pool
consists of the execution callstack and the callstack, where the
superblock was allocated. To better diagnose it I wanted to get also the
callstack of the place where MEMPOOL_FREE was called.
The attached patch uses the new fields added for use-after-free messages
that show two callstacks.
It is just a proof of concept.
How could it be improved?
Regards
Matthias
--- a/memcheck/mc_errors.c
+++ b/memcheck/mc_errors.c
@@ -346,7 +346,15 @@ static void mc_pp_AddrInfo ( Addr a, AddrInfo* ai, Bool maybe_gcc )
);
if (ai-Addr.Block.block_kind==Block_Mallocd) {
VG_(pp_ExeContext)(ai-Addr.Block.allocated_at);
-tl_assert (ai-Addr.Block.freed_at == VG_(null_ExeContext)());
+if (ai-Addr.Block.freed_at != VG_(null_ExeContext)()) {
+ emit(
+ %s block was re-alloced at%s\n,
+ xpre,
+ xpost
+ );
+ VG_(pp_ExeContext)(ai-Addr.Block.freed_at);
+}
+//tl_assert (ai-Addr.Block.freed_at == VG_(null_ExeContext)());
}
else if (ai-Addr.Block.block_kind==Block_Freed) {
VG_(pp_ExeContext)(ai-Addr.Block.freed_at);
@@ -1183,6 +1191,7 @@ static Bool mempool_block_maybe_describe( Addr a, AddrInfo* ai );
static void describe_addr ( Addr a, /*OUT*/AddrInfo* ai )
{
MC_Chunk* mc;
+ MC_Chunk* mc_freed;
ThreadId tid;
Addr stack_min, stack_max;
VgSectKind sect;
@@ -1211,7 +1220,8 @@ static void describe_addr ( Addr a, /*OUT*/AddrInfo* ai )
if (addr_is_in_MC_Chunk_default_REDZONE_SZB(mc, a)) {
ai-tag = Addr_Block;
ai-Addr.Block.block_kind = Block_Mallocd;
- if (MC_(get_freed_block_bracketting)( a ))
+ mc_freed = MC_(get_freed_block_bracketting)( a );
+ if (mc_freed)
ai-Addr.Block.block_desc = recently re-allocated block;
else
ai-Addr.Block.block_desc = block;
@@ -1219,6 +1229,10 @@ static void describe_addr ( Addr a, /*OUT*/AddrInfo* ai )
ai-Addr.Block.rwoffset = (Word)a - (Word)mc-data;
ai-Addr.Block.allocated_at = MC_(allocated_at)(mc);
ai-Addr.Block.freed_at = MC_(freed_at)(mc);
+ if (mc_freed ai-Addr.Block.freed_at == VG_(null_ExeContext)())
+ {
+ai-Addr.Block.freed_at = MC_(freed_at)(mc_freed);
+ }
return;
}
}
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] [PATCH] Thread names in valgrind and vgdb
On 07.11.2012 16:54, Matthias Schwarzott wrote:
Hi!
I wonder if it would be good to have valgrind remember the names of the
threads.
Here is a first implementation of this change.
It just enhances the struct ThreadState by a char array thread_name.
The handler of prctl writes its argument there.
For the first thread it is initialized to main (without valgrind there
is the name of the executable by default, how could I get this).
pp_Error prints Errors like this (if thread name is there):
Thread 2 abcdxyz01234567:
gdbserver appends it at the end for the qThreadExtraInfo query.
(gdb) info threads
Id Target Id Frame
* 2Thread 30698 (tid 2 VgTs_Runnable abcdxyz01234567)
0x004009aa in child_fn (arg=0x0) at threadname.c:32
1Thread 30679 (tid 1 VgTs_Yielding main) 0x0034cfae88d1 in
clone () from /lib64/libc.so.6
The testcase I started to write is also included.
Regards
Matthias
commit 56074382acdf0eb5f77c08aaec7b65a877658823
Author: Matthias Schwarzott z...@gentoo.org
Date: Tue Oct 30 20:39:21 2012 +0100
set thread name
diff --git a/coregrind/m_errormgr.c b/coregrind/m_errormgr.c
index b4fec57..066056b 100644
--- a/coregrind/m_errormgr.c
+++ b/coregrind/m_errormgr.c
@@ -603,7 +603,12 @@ static void pp_Error ( Error* err, Bool allow_db_attach, Bool xml )
if (VG_(tdict).tool_show_ThreadIDs_for_errors
err-tid 0 err-tid != last_tid_printed) {
- VG_(umsg)(Thread %d:\n, err-tid );
+ ThreadState* tst = VG_(get_ThreadState)(err-tid);
+ if (tst-thread_name[0]) {
+VG_(umsg)(Thread %d %s:\n, err-tid, VG_(get_ThreadState)(err-tid)-thread_name);
+ } else {
+VG_(umsg)(Thread %d:\n, err-tid );
+ }
last_tid_printed = err-tid;
}
diff --git a/coregrind/m_gdbserver/server.c b/coregrind/m_gdbserver/server.c
index 5dcb139..277ba59 100644
--- a/coregrind/m_gdbserver/server.c
+++ b/coregrind/m_gdbserver/server.c
@@ -499,9 +499,16 @@ void handle_query (char *arg_own_buf, int *new_packet_len_p)
if (ti != NULL) {
tst = (ThreadState *) inferior_target_data (ti);
/* Additional info is the tid and the thread status. */
+ if (tst-thread_name[0]) {
+ VG_(snprintf) (status, sizeof(status), tid %d %s %s,
+tst-tid,
+VG_(name_of_ThreadStatus)(tst-status),
+ tst-thread_name);
+ } else {
VG_(snprintf) (status, sizeof(status), tid %d %s,
tst-tid,
VG_(name_of_ThreadStatus)(tst-status));
+ }
hexify (arg_own_buf, status, strlen(status));
return;
} else {
diff --git a/coregrind/m_scheduler/scheduler.c b/coregrind/m_scheduler/scheduler.c
index ef41c64..56feac2 100644
--- a/coregrind/m_scheduler/scheduler.c
+++ b/coregrind/m_scheduler/scheduler.c
@@ -236,6 +236,7 @@ ThreadId VG_(alloc_ThreadState) ( void )
if (VG_(threads)[i].status == VgTs_Empty) {
VG_(threads)[i].status = VgTs_Init;
VG_(threads)[i].exitreason = VgSrc_None;
+ VG_(threads)[i].thread_name[0] = 0;
return i;
}
}
@@ -614,6 +615,7 @@ ThreadId VG_(scheduler_init_phase1) ( void )
}
tid_main = VG_(alloc_ThreadState)();
+ VG_(strncpy)(VG_(threads)[tid_main].thread_name, main, sizeof(VG_(threads)[tid_main].thread_name));
/* Bleh. Unfortunately there are various places in the system that
assume that the main thread has a ThreadId of 1.
diff --git a/coregrind/m_syswrap/syswrap-linux.c b/coregrind/m_syswrap/syswrap-linux.c
index 7c94bd5..6cde946 100644
--- a/coregrind/m_syswrap/syswrap-linux.c
+++ b/coregrind/m_syswrap/syswrap-linux.c
@@ -939,6 +939,13 @@ POST(sys_prctl)
case VKI_PR_GET_FPEXC:
POST_MEM_WRITE(ARG2, sizeof(Int));
break;
+ case VKI_PR_SET_NAME:
+ {
+ ThreadState* tst = VG_(get_ThreadState)(tid);
+ VG_(strncpy)(tst-thread_name, (char*)ARG2, 16);
+ tst-thread_name[16] = 0;
+ }
+ break;
case VKI_PR_GET_NAME:
POST_MEM_WRITE(ARG2, VKI_TASK_COMM_LEN);
break;
diff --git a/coregrind/pub_core_threadstate.h b/coregrind/pub_core_threadstate.h
index 0bd9927..73ee947 100644
--- a/coregrind/pub_core_threadstate.h
+++ b/coregrind/pub_core_threadstate.h
@@ -353,6 +353,8 @@ typedef struct {
/* Per-thread jmp_buf to resume scheduler after a signal */
Bool sched_jmpbuf_valid;
VG_MINIMAL_JMP_BUF(sched_jmpbuf);
+
+ char thread_name[17];
}
ThreadState;
diff --git a/memcheck/tests/Makefile.am b/memcheck/tests/Makefile.am
index cf1d5cc..4bfce22 100644
--- a/memcheck/tests/Makefile.am
+++ b/memcheck/tests/Makefile.am
@@ -228,7 +228,8 @@ EXTRA_DIST = \
wrap8.vgtest wrap8.stdout.exp wrap8.stderr.exp \
wrap8.stdout.exp2 wrap8.stderr.exp2 \
writev1.stderr.exp writev1.vgtest \
- xml1.stderr.exp xml1.stdout.exp xml1.vgtest xml1.stderr.exp-s390x-mvc
+ xml1.stderr.exp xml1.stdout.exp xml1.vgtest xml1.stderr.exp-s390x-mvc \
+ threadname.vgtest
Re: [Valgrind-users] Thread names in valgrind and vgdb
On 10.11.2012 18:24, Philippe Waroquiers wrote: On Fri, 2012-11-09 at 07:52 -0700, Tom Tromey wrote: Matthias Using plain gdb, info threads also lists these user-defined names. Matthias But valgrind and gdb+vgdb only show the thread-ids. Currently I don't think there is a way for vgdb to report this back to gdb. The thread name could be reported via packet qThreadExtraInfo, shown in 'info threads' (this is how Valgrind gdbsrv shows e.g. the Valgrind thread state and id). This extra info is just a string, and so GDB will not be able to understand it contains a thread name. Yes, this is the way I implemented my proof of concept. A bit of googling shows that kgdb (the kernel gdbserver) also sends the comm field (the thread name) in qThreadExtraInfo. I will send a patch tomorrow. Matthias -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ 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] Improving prlimit64 / setrlimit64 / getrlimit64
On 10.02.2012 01:21, Tom Hughes wrote: On 09/02/12 20:36, Matthias Schwarzott wrote: The attached patch applies against valgrind svn revision 12373. Tested on a Gentoo amd64 installation built for 64bit and also built for 32bit (with --enable-only32bit). Please open a bug in the bug tracker and attach your patch to it so that it doesn't get lost. Tom I created https://bugs.kde.org/show_bug.cgi?id=294047 and attached a new version of the patch there. The attached patch does this: Change prlimit64 to behave like a combination of the existing setrlimit and getrlimit. Run emulation only if ARG0 (pid) is 0 or equal getpid() improve setrlimit (like new prlimit64) to return EINVAL if softlimithardlimit Add tests (using getrlimit64 and setrlimit64) TODO: Tests using prlimit and prlimit64 (perhaps with different pid values) on x86: getrlimit - syscall getrlimit setrlimit - syscall setrlimit prlimit - syscall prlimit64 getrlimit64 - syscall prlimit64 setrlimit64 - syscall prlimit64 prlimit64 - syscall prlimit64 on amd64: getrlimit - syscall getrlimit setrlimit - syscall setrlimit prlimit - syscall prlimit64 getrlimit64 - syscall getrlimit setrlimit64 - syscall setrlimit prlimit64 - syscall prlimit64 Regards Matthias -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] Improving prlimit64 / setrlimit64 / getrlimit64
Hi all,
I tried to run a win32 application under valgrind+wine on a gentoo x86
installation.
Sadly this failed on an internal error like in
https://bugs.kde.org/show_bug.cgi?id=275673
The error looks like this part from the bug:
strace.txt:61324:[pid 2563] pipe([20, 21]) = 0
strace.txt:61325:[pid 2563] fcntl(20, F_DUPFD, 1014)= -1 EINVAL
(Invalid
argument)
strace.txt:61327:[pid 2563] gettid()= 2563
strace.txt:61408:[pid 2563] fcntl(-1, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad
file descriptor)
strace.txt:61413:[pid 2563] gettid()= 2563
strace.txt:61509:[pid 2563] poll([{fd=1019, events=POLLIN}], 1, -1
The duplicating of the fd fails.
The reason is, that before prlimit64 is called to change RLIMIT_NOFILE.
But valgrind does not emulate it like setrlimit and getrlimit.
(The second call to set FD_CLOEXEC could be avoided on error of F_DUPFD
before.)
I changed valgrind to make prlimit64 behave like the setrlimit and
getrlimit syscalls.
The patch also contains a testcase for setrlimit64 and getrlimit64 for
fileno.
I needed to move all code to the pre-handler, as it is possible to call
prlimit64 with both set and get parameter.
This also deserves a testcase.
What also is missing is: only using the emulation if pid is 0 or equal
the current pid.
The attached patch applies against valgrind svn revision 12373.
Tested on a Gentoo amd64 installation built for 64bit and also built for
32bit (with --enable-only32bit).
Regards,
Matthias
Add better implementation of prlimit64
improve prlimit64
improve setrlimit to return EINVAL if softlimithardlimit
add tests for all that
v4
The emulation should only happen if ARG0(pid) == 0 or equal getpid()
diff --git a/coregrind/m_syswrap/syswrap-generic.c b/coregrind/m_syswrap/syswrap-generic.c
index 18f2a5f..275c5d1 100644
--- a/coregrind/m_syswrap/syswrap-generic.c
+++ b/coregrind/m_syswrap/syswrap-generic.c
@@ -3908,6 +3908,14 @@ PRE(sys_setrlimit)
arg1 = ~_RLIMIT_POSIX_FLAG;
#endif
+ if (ARG2) {
+ if (((struct vki_rlimit *)ARG2)-rlim_cur ((struct vki_rlimit *)ARG2)-rlim_max)
+ {
+ SET_STATUS_Failure( VKI_EINVAL );
+ return;
+ }
+ }
+
if (arg1 == VKI_RLIMIT_NOFILE) {
if (((struct vki_rlimit *)ARG2)-rlim_cur VG_(fd_hard_limit) ||
((struct vki_rlimit *)ARG2)-rlim_max != VG_(fd_hard_limit)) {
diff --git a/coregrind/m_syswrap/syswrap-linux.c b/coregrind/m_syswrap/syswrap-linux.c
index 5a62f59..5a63d67 100644
--- a/coregrind/m_syswrap/syswrap-linux.c
+++ b/coregrind/m_syswrap/syswrap-linux.c
@@ -1285,32 +1285,80 @@ PRE(sys_prlimit64)
PRE_MEM_READ( rlimit64(new_rlim), ARG3, sizeof(struct vki_rlimit64) );
if (ARG4)
PRE_MEM_WRITE( rlimit64(old_rlim), ARG4, sizeof(struct vki_rlimit64) );
-}
-POST(sys_prlimit64)
-{
- if (ARG4) {
- POST_MEM_WRITE( ARG4, sizeof(struct vki_rlimit64) );
+ if (ARG3) {
+ if (((struct vki_rlimit64 *)ARG3)-rlim_cur ((struct vki_rlimit64 *)ARG3)-rlim_max)
+ {
+ SET_STATUS_Failure( VKI_EINVAL );
+ return;
+ }
+ }
+ if (ARG1 == 0) {
switch (ARG2) {
case VKI_RLIMIT_NOFILE:
- ((struct vki_rlimit64 *)ARG4)-rlim_cur = VG_(fd_soft_limit);
- ((struct vki_rlimit64 *)ARG4)-rlim_max = VG_(fd_hard_limit);
+ SET_STATUS_Success( 0 );
+ if (ARG4) {
+((struct vki_rlimit64 *)ARG4)-rlim_cur = VG_(fd_soft_limit);
+((struct vki_rlimit64 *)ARG4)-rlim_max = VG_(fd_hard_limit);
+ }
+ if (ARG3) {
+if (((struct vki_rlimit64 *)ARG3)-rlim_cur VG_(fd_hard_limit) ||
+((struct vki_rlimit64 *)ARG3)-rlim_max != VG_(fd_hard_limit)) {
+ SET_STATUS_Failure( VKI_EPERM );
+}
+else {
+ VG_(fd_soft_limit) = ((struct vki_rlimit64 *)ARG3)-rlim_cur;
+}
+ }
break;
case VKI_RLIMIT_DATA:
- ((struct vki_rlimit64 *)ARG4)-rlim_cur = VG_(client_rlimit_data).rlim_cur;
- ((struct vki_rlimit64 *)ARG4)-rlim_max = VG_(client_rlimit_data).rlim_max;
+ SET_STATUS_Success( 0 );
+ if (ARG4) {
+((struct vki_rlimit64 *)ARG4)-rlim_cur = VG_(client_rlimit_data).rlim_cur;
+((struct vki_rlimit64 *)ARG4)-rlim_max = VG_(client_rlimit_data).rlim_max;
+ }
+ if (ARG3) {
+if (((struct vki_rlimit64 *)ARG3)-rlim_cur VG_(client_rlimit_data).rlim_max ||
+((struct vki_rlimit64 *)ARG3)-rlim_max VG_(client_rlimit_data).rlim_max) {
+ SET_STATUS_Failure( VKI_EPERM );
+}
+else {
+ VG_(client_rlimit_data).rlim_cur = ((struct vki_rlimit64 *)ARG3)-rlim_cur;
+ VG_(client_rlimit_data).rlim_max = ((struct vki_rlimit64 *)ARG3)-rlim_max;
+}
+ }
break;
case VKI_RLIMIT_STACK:
- ((struct
