|
From: Julian S. <js...@ac...> - 2006-05-09 01:50:50
|
> *** glibc detected *** grompp: realloc(): invalid pointer: 0x04120008 *** Are you sure your program is really correct? It looks like it's passing a bogus pointer to realloc. > can anybody help me with a solution or a workaround plzzzz. Use 'valgrind --tool=memcheck' to find any such bugs, and fix them. Then try again with the profiler. J |
|
From: Morten W. J. <mo...@ne...> - 2006-05-17 05:42:49
|
=2D-=20 Morten W. J=F8rgensen Newtec A/S St=E6rmoseg=E5rdsvej 18 5230 Odense M Denmark Tlf.: 66 15 84 44 |
|
From: George N. <gna...@gm...> - 2006-05-18 17:03:42
|
unsubscribe |
|
From: Jaskaran S. <jas...@pe...> - 2006-06-01 05:33:22
|
Unsubscribe=0D=0A =0D=0A DISCLAIMER=0A =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A This e-mail may contain privileged and confidential information which is = the property of Persistent Systems Pvt. Ltd. It is intended only for the = use of the individual or entity to which it is addressed. If you are not = the intended recipient, you are not authorized to read, retain, copy, pri= nt, distribute or use this message. If you have received this communicati= on in error, please notify the sender and delete all copies of this messa= ge. Persistent Systems Pvt. Ltd. does not accept any liability for virus = infected mails.=0D=0A |
|
From: Sanders, R. M. <san...@za...> - 2006-08-15 17:53:42
|
Hello all, A quick question. I just downloaded valgrind 3.2 and build in on our DL380G2's running RH. I'm seeing a message about 'silly args (-<big number>) to malloc', but there is no location specified for *who* is sending the bogus values to calloc. Is this message internal to valgrind, or a real indication that my code is doing something it ought not. I'm putting in some checks to my code to verify the args to malloc/calloc/realloc now to vet my code. Rob |
|
From: Nicholas N. <nj...@cs...> - 2006-08-15 22:54:29
Attachments:
diff
|
On Tue, 15 Aug 2006, Sanders, Rob M. wrote: > A quick question. I just downloaded valgrind 3.2 and build in on our > DL380G2's running RH. I'm > seeing a message about 'silly args (-<big number>) to malloc', but there > is no location specified for > *who* is sending the bogus values to calloc. Is this message internal > to valgrind, or a real indication > that my code is doing something it ought not. I'm putting in some > checks to my code to verify the args > to malloc/calloc/realloc now to vet my code. It's a real indication. Memcheck doesn't flag it as a "proper" error (with stack trace) because it's very rare and we've been to lazy to make it a proper error -- that requires adding a new error type, making it suppressible, etc. The attached diff will make Memcheck print a stack trace when this warning is shown. Perhaps we should always do that. Or we could do that but only print the warning three times, then say "I won't print it any more". Nick |
|
From: Tom H. <th...@cy...> - 2006-11-02 08:43:40
|
To: val...@li...
Subject: Re: [Valgrind-users] Code memchecks clean, but core dumps under
callgrind - help?
References: <177...@yt...>
From: Tom Hughes <to...@co...>
Organization: Just Me
Date: Thu, 02 Nov 2006 08:42:53 +0000
In-Reply-To: <177...@yt...> (Dave Steffen's
message of "Wed, 1 Nov 2006 11:09:50 -0700")
Message-ID: <yek...@de...>
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In message <177...@yt...>
Dave Steffen <dgs...@nu...> wrote:
> ==26931== Process terminating with default action of signal 6 (SIGABRT): dumping core
> ==26931== at 0x4159805: raise (in /lib/tls/libc-2.3.3.so)
> ==26931== by 0x415B1E8: abort (in /lib/tls/libc-2.3.3.so)
> ==26931== by 0x40CD7C4: __cxxabiv1::__terminate(void (*)()) (in /usr/lib/libstdc++.so.5.0.6)
> ==26931== by 0x40CD801: std::terminate() (in /usr/lib/libstdc++.so.5.0.6)
> ==26931== by 0x40CD981: __cxa_throw (in /usr/lib/libstdc++.so.5.0.6)
> ==26931== by 0x40CDBC2: operator new(unsigned) (in /usr/lib/libstdc++.so.5.0.6)
> ==26931== by 0x817BA03: boost::any::any<float>(float const&) (any.hpp:33)
> ==26931== by 0x817B9D9: Numerica::PropertyWrapper::PropertyWrapper<float>(float) (Properties.h:64)
> ==26931== by 0x817B968: void Numerica::Properties::setProperty<float>(std::string const&, float) (Properties.h:115)
> ==26931== by 0x81797A4: void Numerica::ExternalProperties::setExternalProperty<float>(std::string const&, float) (ExternalProperties.h:53)
> ==26931== by 0x81782D6: Numerica::ONIRMessageTranslator::translateReturn(Messages::ReturnMsg const&, boost::shared_ptr<Numerica::ONIRSensorCommon> const&, double, Numerica::Matrix const&, Messages::FrameMsgheader const&) (ONIRMessageTranslator.C:181)
> ==26931== by 0x8176FA9: Numerica::ONIRMessageTranslator::translateFrameMsg(Messages::FrameMsg const&, double, Numerica::Matrix const&) (ONIRMessageTranslator.C:27)
That looks to me like you've just run out of memory when running it
under callgrind...
You have an operator new that has thrown an exception, probably an out
of memory exception, which has not been caught so std::terminate is
called which stops the process by calling abort.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Paul F. <pa...@fr...> - 2006-11-15 17:37:58
|
Hi
(I don't have access to the latest code, so I can't tell if it's been fix=
ed).
I just spotted the following:
m_main.c
case OverlapSupp:
return (ekind =3D OverlapErr);
I was scratching my head wondering why my Overlap suppressions were not w=
orking!
A+
Paul
|
|
From: Paul F. <pa...@fr...> - 2006-11-15 17:55:00
|
Quoting Paul Floyd <pa...@fr...>: > Hi > > (I don't have access to the latest code, so I can't tell if it's been f= ixed). > > I just spotted the following: > > m_main.c > > > case OverlapSupp: > return (ekind =3D OverlapErr); > > I was scratching my head wondering why my Overlap suppressions were not > working! Hmm. Still not working (with =3D=3D instead). A+ Paul |
|
From: mohit t. <tew...@ya...> - 2007-03-29 12:05:20
|
Hello, In response to ecsezer's question about tracking just the client address space bounds, I thought of trying to see _all_ addresses currently in use by the client. So I printed out, in mc_main.c, the address ranges being marked using "static void set_address_range_perms ( Addr a, SizeT lenT, UWord vabits16, UWord dsm_num)". Oddly though, when I ran valgrind on ls, I found an address range being marked Defined when a superset of it was already marked Defined. Is that allowed, ie, can an address currently marked defined be done so again, before deallocating it first? Or is there some other way the contentious subset could have been marked Undefined / NoAccess... Mohit This is using Valgrind-3.2.3. The address range trace was as below: --------- begin --------- 648000 ,size 86016 ,valid 2 ,DSMnum 2 65D000 ,size 4096 ,valid 2 ,DSMnum 2 8048000 ,size 16384 ,valid 2 ,DSMnum 2 804C000 ,size 8192 ,valid 2 ,DSMnum 2 804E000 ,size 4096 ,valid 2 ,DSMnum 2 38021000 ,size 4096 ,valid 2 ,DSMnum 2 <--- Superset marked defined BEF39000 ,size 4096 ,valid 2 ,DSMnum 2 BEF39000 ,size 2560 ,valid 0 ,DSMnum 0 38021D7C ,size 56 ,valid 2 ,DSMnum 2 <--- Subset marked defined... --------- trimmed -------- ____________________________________________________________________________________ Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html |
|
From: Nicholas N. <nj...@cs...> - 2007-03-29 12:46:36
|
On Thu, 29 Mar 2007, mohit tewari wrote: > Oddly though, when I ran valgrind on ls, I found an address range being > marked Defined when a superset of it was already marked Defined. Is that > allowed, ie, can an address currently marked defined be done so again, > before deallocating it first? Or is there some other way the contentious > subset could have been marked Undefined / NoAccess... That's expected. For example, you might have a block of defined memory, and then you execute a read() system call which overwrites the defined memory with more defined memory. There are probably many more cases like that. Nick |
|
From: sunil k. <su...@gm...> - 2007-04-05 13:54:15
|
Hi All, I am getting following error while using valgrind can anybody explain reason behind this. Because of this am not able to test my program furthur. ==8195== 1. Your program has a bug and erroneously jumped to a non-code ==8195== location. If you are running Memcheck and you just saw a ==8195== warning about a bad jump, it's probably your program's fault. ==8195== 2. The instruction is legitimate but Valgrind doesn't handle it, ==8195== i.e. it's Valgrind's fault. If you think this is the case or ==8195== you are not sure, please let us know and we'll try to fix it. ==8195== Either way, Valgrind will now raise a SIGILL signal which will ==8195== probably kill your program. ==8195== ==8195== Process terminating with default action of signal 4 (SIGILL) ==8195== Illegal opcode at address 0x4999BC ==8195== at 0x4999BC: inb (io.h:48) Thanks & Regards, -- Sunil |
|
From: Paul F. <pa...@fr...> - 2007-06-11 15:04:18
|
Hi again One of my colleagues recently had a Valgrind crash with the following stack: --12039-- VALGRIND INTERNAL ERROR: Valgrind received a signal 7 (SIGBUS) - exiting --12039-- si_code=2; Faulting address: 0x9338308; sp: 0x646EB53C valgrind: the 'impossible' happened: Killed by fatal signal ==12039== at 0x380C844B: disInstr_X86_WRK (toIR.c:7190) ==12039== by 0x380DA965: disInstr_X86 (toIR.c:13047) ==12039== by 0x380A8CEA: bb_to_IR (bb_to_IR.c:228) ==12039== by 0x38075E6C: LibVEX_Translate (vex_main.c:426) ==12039== by 0x3802B3BC: vgPlain_translate (m_translate.c:1097) ==12039== by 0x3803850A: handle_tt_miss (scheduler.c:693) ==12039== by 0x38038ADB: vgPlain_scheduler (scheduler.c:865) ==12039== by 0x3804CA86: thread_wrapper (syswrap-linux.c:87) ==12039== by 0x3804CB9D: run_a_thread_NORETURN (syswrap-linux.c:120) (with Valgrind 3.2.1 on RHEL 3.0 kernel 2.4.21-4.ELsmp) Looking at toIR.c:7190, it seems to be just accessing a table - not an obvious site for a sigbus. I don't have much of a clue how to proceed. A+ Paul |
|
From: Julian S. <js...@ac...> - 2007-06-18 11:18:20
|
SIGBUSes tend to be symptomatic of executables being unmapped or changed (eg, relinked) as they are running. Could that be the case here? J On Monday 11 June 2007 17:04, Paul Floyd wrote: > Hi again > > One of my colleagues recently had a Valgrind crash with the following > stack: > > --12039-- VALGRIND INTERNAL ERROR: Valgrind received a signal 7 (SIGBUS) - > exiting > --12039-- si_code=2; Faulting address: 0x9338308; sp: 0x646EB53C > > valgrind: the 'impossible' happened: > Killed by fatal signal > ==12039== at 0x380C844B: disInstr_X86_WRK (toIR.c:7190) > ==12039== by 0x380DA965: disInstr_X86 (toIR.c:13047) > ==12039== by 0x380A8CEA: bb_to_IR (bb_to_IR.c:228) > ==12039== by 0x38075E6C: LibVEX_Translate (vex_main.c:426) > ==12039== by 0x3802B3BC: vgPlain_translate (m_translate.c:1097) > ==12039== by 0x3803850A: handle_tt_miss (scheduler.c:693) > ==12039== by 0x38038ADB: vgPlain_scheduler (scheduler.c:865) > ==12039== by 0x3804CA86: thread_wrapper (syswrap-linux.c:87) > ==12039== by 0x3804CB9D: run_a_thread_NORETURN (syswrap-linux.c:120) > > (with Valgrind 3.2.1 on RHEL 3.0 kernel 2.4.21-4.ELsmp) > > Looking at toIR.c:7190, it seems to be just accessing a table - not an > obvious site for a sigbus. I don't have much of a clue how to proceed. > > A+ > Paul > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Mulgund, A. D. (LNG-DAY) <Ana...@le...> - 2008-01-30 19:41:23
|
Is there a port available or plan for IBM z/OS Linux? |
|
From: Florian K. <br...@ac...> - 2008-01-31 04:00:34
|
On Wednesday 30 January 2008 2:41:20 pm Mulgund, Anand D. (LNG-DAY) wrote: > Is there a port available or plan for IBM z/OS Linux? > valgrind has not been ported to Linux for z/series. Florian |
|
From: andrew t. <and...@ma...> - 2008-08-19 06:46:20
|
Dear Sir, I have an question for you. I built my project code to be an binary(image) and upload to our device, Wireless Router. I would like to use the Valgrind to find memory leak. How should I do that? I just know to simulate on PC with JTAG, USB or LAN when the chip set debugging function is available. Our device have LAN only without debugging function as far as I knew. How should I do simulate Valgrind with our device? Re-built our code with Valgrind source code? Thanks,Best Regards,AndrewChang. -- Be Yourself @ mail.com! Choose From 200+ Email Addresses Get a Free Account at www.mail.com |
|
From: Silvano C. <cat...@ya...> - 2008-12-01 22:20:07
|
Hello, I am writing an XML database. It is composed by four components: 1) wgClibs // generic C lib 2) wgCppLibs // general purples C++ classes 3) WNPComm // IPC library using named-pipe 4) wlxdb // the light xml database Every components has its own test programs.. VG returns me 0 error for C and C++ libs both. But the problems begin with WNPComm... Its core has been developed in pure C, but in order to use this library in C++ I have written a class that provides all functionalities of WNPComm. The C core (WNPComm.c) functions very well and VG gives me 0 error. But the VG tests on Cpp wrapper class returns me impossible errors!! I have tried to leave the Cpp class (CppWNPComm.cpp) empty, also the test empty, and no link to the core. g++ -Wall CppWNPComm.cpp -c -o CppWNPComm.o -D__DEBUG__=0 ar rcs libCppWNPComm.a CppWNPComm.o g++ -Wall CppWNPComm.cpp -c -o CppWNPComm-sh.o -D__DEBUG__=0 -fPIC LD_RUN_PATH=../C g++ -shared CppWNPComm-sh.o -lwgc -lwgcpp -L../C -o libCppWNPComm.so VG returned me 0 errors: ==4813== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 23 from 1) ==4813== malloc/free: in use at exit: 0 bytes in 0 blocks. ==4813== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==4813== For counts of detected errors, rerun with: -v ==4813== All heap blocks were freed -- no leaks are possible. BUT, if I leave the files empty but I link the (C++) CppWNPComm to (C) WNPComm then strange tings happend g++ -Wall CppWNPComm.cpp -c -o CppWNPComm.o -D__DEBUG__=0 ar rcs libCppWNPComm.a CppWNPComm.o g++ -Wall CppWNPComm.cpp -c -o CppWNPComm-sh.o -D__DEBUG__=0 -fPIC LD_RUN_PATH=../C g++ -shared CppWNPComm-sh.o -lwgc -lwgcpp -L../C -lWNPComm -o libCppWNPComm.so When I check the empty files executablem VG returns me strange errors: r:[Cpp_test]$ valgrind ./test_server ==4934== Memcheck, a memory error detector. ==4934== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==4934== Using LibVEX rev 1854, a library for dynamic binary translation. ==4934== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==4934== Using valgrind-3.3.1, a dynamic binary instrumentation framework. ==4934== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==4934== For more details, rerun with: -v ==4934== ==4934== Invalid free() / delete / delete[] ==4934== at 0x4023389: free (vg_replace_malloc.c:323) ==4934== by 0x42829EB: free_mem (in /lib/libc-2.7.so) ==4934== by 0x4282533: __libc_freeres (in /lib/libc-2.7.so) ==4934== by 0x401F1E3: _vgnU_freeres (vg_preloaded.c:60) ==4934== by 0x4199C07: exit (in /lib/libc-2.7.so) ==4934== by 0x4182397: (below main) (in /lib/libc-2.7.so) ==4934== Address 0x413a850 is not stack'd, malloc'd or (recently) free'd ==4934== ==4934== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 25 from 1) ==4934== malloc/free: in use at exit: 0 bytes in 0 blocks. ==4934== malloc/free: 0 allocs, 1 frees, 0 bytes allocated. ==4934== For counts of detected errors, rerun with: -v ==4934== All heap blocks were freed -- no leaks are possible. How can I have allocation error here? the files was enpt! I have already rebuild gcc with GLIBCXX_FORCE_NEW otion but nothing changes. The address of my OSS is http://linuxwoodo.svn.sourceforge.net Please, until I do not understand why I cannot continue my OSS project. I hope someone will have some idea Thank you so much Silvano |
|
From: Andrew M. <And...@as...> - 2009-04-08 13:01:08
|
I am trying to use Valgrind to check my Fortran MPI code. I haven't compiled the MPI wrapper as it won't compile (the 'compile with -fPIC' error). I am using Valgrind 3.4.1 (downloaded and compiled it early after trying it with 3.2.1). The code is standard F95/2003 and I am using the Sun compiler. When I try and run my code, using the command line: mpiexec -n 4 valgrind --leak-check=yes -v -v ./seren BBmpiparams.dat or even just valgrind --leak-check=yes -v -v ./seren BBmpiparams.dat (which works as a single process run) I get this output: ==16655== Memcheck, a memory error detector. ==16655== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al. ==16655== Using LibVEX rev 1884, a library for dynamic binary translation. ==16655== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. ==16655== Using valgrind-3.4.1, a dynamic binary instrumentation framework. ==16655== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. ==16655== --16655-- Command line --16655-- ./seren --16655-- BBmpiparams.dat --16655-- Startup, with flags: --16655-- --leak-check=yes --16655-- -v --16655-- -v --16655-- Contents of /proc/version: --16655-- Linux version 2.6.18-53.1.14.el5 (bre...@no...) (gcc version 4.1.2 20070626 (Red Hat 4.1.2-14)) #1 SMP Wed Mar 5 10:08:25 EST 200 8 --16655-- Arch and hwcaps: AMD64, amd64-sse2 --16655-- Page sizes: currently 4096, max supported 4096 --16655-- Valgrind library directory: /home/ophiuchus/spxam/valgrind/lib/valgrind --16655-- TT/TC: VG_(init_tt_tc) (startup of code management) --16655-- TT/TC: cache: 8 sectors of 29772288 bytes each = 238178304 total --16655-- TT/TC: table: 524168 total entries, max occupancy 419328 (80%) --16655-- Reading syms from /home/ophiuchus/spxam/codes/seren-mpi/seren (0x400000) --16655-- svma 0x0000403960, avma 0x0000403960 --16655-- DWARF2 CFI reader: unhandled CFI instruction 0:8 (lots and lots and lots of DWARF2 CFI reader errors) --16655-- Reading syms from /home/ophiuchus/spxam/valgrind/lib/valgrind/amd64-linux/memcheck (0x38000000) --16655-- svma 0x00380000f0, avma 0x00380000f0 --16655-- object doesn't have a dynamic symbol table --16655-- Reading syms from /lib64/ld-2.5.so (0x3ebe800000) --16655-- svma 0x3ebe800a60, avma 0x3ebe800a60 --16655-- summarise_context(loc_start = 0xa3): cannot summarise(why=1): 0xc9: 104(r1) u c-32 u u u u u u u u u u u u u u c-8 u u u --16655-- summarise_context(loc_start = 0x21): cannot summarise(why=1): 0x3e: 0(r5) u u u c0 u u c8 r8 u u u u c16 c24 c32 c40 r1 u u u --16655-- Reading suppressions file: /home/ophiuchus/spxam/valgrind/lib/valgrind/default.supp --16655-- TT/TC: initialise sector 0 --16655-- Reading syms from /home/ophiuchus/spxam/valgrind/lib/valgrind/amd64-linux/vgpreload_core.so (0x4802000) --16655-- svma 0x0000000440, avma 0x0004802440 --16655-- Reading syms from /home/ophiuchus/spxam/valgrind/lib/valgrind/amd64-linux/vgpreload_memcheck.so (0x4a03000) --16655-- svma 0x0000001ae0, avma 0x0004a04ae0 --16655-- REDIR: 0x3ebe8142d0 (index) redirected to 0x4a06e10 (index) --16655-- REDIR: 0x3ebe814480 (strcmp) redirected to 0x4a07070 (strcmp) --16655-- REDIR: 0x3ebe8144b0 (strlen) redirected to 0x4a06fa0 (strlen) --16655-- Reading syms from /lib64/libpthread-2.5.so (0x3ec0400000) --16655-- svma 0x3ec0405210, avma 0x3ec0405210 --16655-- Reading syms from /lib64/librt-2.5.so (0x3ec4000000) --16655-- svma 0x3ec4002230, avma 0x3ec4002230 --16655-- Reading syms from /home/ophiuchus/spxam/sunstudio/sunstudio12/prod/lib/amd64/libfui.so.1 (0x4c2f000) --16655-- svma 0x0000003cf0, avma 0x0004c32cf0 --16655-- DWARF2 CFI reader: unhandled CFI instruction 0:8 (lots more of these errors) Occasional other messages: --16655-- Reading syms from /home/ophiuchus/spxam/sunstudio/sunstudio12/prod/lib/amd64/libfai.so.1 (0x4d3e000) --16655-- svma 0x0000002940, avma 0x0004d40940 --16655-- Reading syms from /home/ophiuchus/spxam/sunstudio/sunstudio12/prod/lib/amd64/libfsu.so.1 (0x5b80000) --16655-- svma 0x0000010ef0, avma 0x0005b90ef0 --16655-- Reading syms from /home/ophiuchus/spxam/sunstudio/sunstudio12/rtlibs/amd64/libmtsk.so.1 (0x5fc4000) --16655-- svma 0x00000042a0, avma 0x0005fc82a0 then finally: --16655-- Reading syms from /lib64/libm-2.5.so (0x3ebfc00000) --16655-- svma 0x3ebfc03e80, avma 0x3ebfc03e80 --16655-- Reading syms from /lib64/libc-2.5.so (0x3ebf800000) --16655-- svma 0x3ebf81d690, avma 0x3ebf81d690 --16655-- summarise_context(loc_start = 0x27): cannot summarise(why=1): 0x44: 0(r5) u u u c0 u u c8 r8 u u u u c16 c24 c32 c40 r1 u u u --16655-- summarise_context(loc_start = 0x35): cannot summarise(why=1): 0x7d: 0(r5) u u u c128 u u c120 c160 u u u u c72 c80 c88 c96 c168 u u u --16655-- Reading syms from /lib64/libdl-2.5.so (0x3ec0000000) --16655-- svma 0x3ec0000e20, avma 0x3ec0000e20 --16655-- REDIR: 0x3ebf877320 (memset) redirected to 0x4a07210 (memset) --16655-- REDIR: 0x3ebf877a40 (memcpy) redirected to 0x4a08210 (memcpy) --16655-- REDIR: 0x3ebf876470 (rindex) redirected to 0x4a06cc0 (rindex) --16655-- REDIR: 0x3ebf8708b0 (calloc) redirected to 0x4a05060 (calloc) --16655-- REDIR: 0x3ebe814b00 (stpcpy) redirected to 0x4a07b50 (stpcpy) --16655-- REDIR: 0x3ebf870c20 (malloc) redirected to 0x4a05f50 (malloc) --16655-- REDIR: 0x3ebf8729e0 (free) redirected to 0x4a05ad0 (free) --16655-- REDIR: 0x3ebf876080 (strlen) redirected to 0x4a06f60 (strlen) --16655-- REDIR: 0x3ebf876300 (strncmp) redirected to 0x4a06fc0 (strncmp) Finally it just quit out with a SEGFAULT. Mostly just the DWARF2 CFI reader error (hundreds of this error). Does anyone have any ideas why this is happening? I've never used Valgrind before; just to check Valgrind ran at all I tested: valgrind --leak-check=yes echo "some text" and that worked. Many thanks, Andrew McLeod |
|
From: Tom H. <to...@co...> - 2009-04-08 13:24:30
Attachments:
valgrind-cfa-same-value.patch
|
Andrew McLeod wrote: > Finally it just quit out with a SEGFAULT. > > Mostly just the DWARF2 CFI reader error (hundreds of this error). The attached patch should fix the DWARF errors - please let me know if it does. I don't think it will help with the crash though - all those errors mean is that it hasn't been able to decode some of the debug information which will just mean it may have trouble unwinding the stack when reporting an error. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: sam s. <sun...@gm...> - 2010-03-31 14:55:36
|
http://rapidshare.com/files/370319208/v1.2.exe |
|
From: Nigel S. <nig...@ho...> - 2011-09-29 23:04:29
|
http://www.bodybeautifuldirect.com/blog.php?html120 |
|
From: Spikey D. <se...@ca...> - 2012-05-15 20:39:31
|
I initially forgot to use --prefix=/usr/bin when I invoked ./configure. I did that later, and then used make and make install. It would appear I typed in something wrong, as valgrind is actually installed in /usr/bin/bin. However, I've added that path to my .profile for bash so it finds the program. Now, I am getting an error: valgrind: Unknown/uninstalled VG_PLATFORM 'amd64-darwin' I've hunted around through some forums and a similar problem having to do with brew suggested that the permissions on various vgpreload_* files may not be correct. I found two instances of these files, both in: /usr/bin/lib/valgrind/ and also in /usr/bin/lib/valgrind/vgpreload_*.so.dSYM/Contents/Resources/DWARF/vgpreload*.so (occurs for each preload file). All of the ones in the first directory mentioned already have execute permissions; I forcefully added execute permissions to the ones in the latter directories and the error remains the same... Suggestions? |
|
From: Tom H. <to...@co...> - 2012-05-15 21:33:12
|
On 15/05/12 21:24, Spikey Dog wrote: > I initially forgot to use --prefix=/usr/bin when I invoked ./configure. > I did that later, and then used make and make install. It would appear I > typed in something wrong, as valgrind is actually installed in > /usr/bin/bin. However, I've added that path to my .profile for bash so > it finds the program. Now, I am getting an error: valgrind: > Unknown/uninstalled VG_PLATFORM 'amd64-darwin' Your problem is that you want prefix=/usr, not prefix=/usr/bin as prefix is, as it's name suggests, a prefix, to which specific directories like bin and lib are then added. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: David S. <drs...@gm...> - 2012-05-17 14:09:50
|
Hello Valgrind users, Please help me diagnose the following configure error on a x86_64/Linux system. I searched google for solutions, but found none. The error seems or originate in [gcc-version] in configure.in. Thanks! Dave [sunfire02:~/packages/valgrind-3.7.0] % $CC --version gcc4 (GCC) 4.6.0 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [sunfire02:~/packages/valgrind-3.7.0] % ./configure --prefix=/u/drsmith/local --with-mpicc=mpicc checking for a BSD-compatible install... /u/drsmith/local/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking whether ln -s works... yes checking for gcc... gcc4 checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc4 accepts -g... yes checking for gcc4 option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc4... gcc3 checking whether gcc4 and cc understand -c and -o together... yes checking how to run the C preprocessor... gcc4 -E checking whether we are using the GNU C++ compiler... yes checking whether g++4 accepts -g... yes checking dependency style of g++4... gcc3 checking for ranlib... ranlib checking for a sed that does not truncate output... /bin/sed checking for ar... /usr/bin/ar checking for perl... /usr/bin/perl checking for gdb... /usr/bin/gdb checking dependency style of gcc4... gcc3 checking for diff -u... yes checking for a supported version of gcc... no (4) configure: error: please use gcc >= 3.0 or clang >= 2.9 [sunfire02:~/packages/valgrind-3.7.0] % |