You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(8) |
2
(10) |
|
3
|
4
|
5
(7) |
6
(12) |
7
(8) |
8
(3) |
9
|
|
10
|
11
(7) |
12
|
13
(2) |
14
(2) |
15
(10) |
16
(4) |
|
17
|
18
(14) |
19
(11) |
20
(12) |
21
(4) |
22
(2) |
23
(3) |
|
24
|
25
|
26
|
27
(8) |
28
(7) |
29
(3) |
30
(1) |
|
From: Fred S. <fr...@co...> - 2005-04-06 19:40:05
|
I'm getting a LOT of items like those below, I can't figure out how to manually create suppressions for them and the auto-generated suppressions aren't working for these items either (see my previous posting from earlier today). =0D Can someone give me a hint on how to suppress these things? They aren't a Value4, or any other defined type that I can figure out.... =0D =3D=3D20816=3D=3D Conditional jump or move depends on uninitialised= value(s) =3D=3D20816=3D=3D at 0x1C0FAA79: lmmmalloc (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1C154390: lmmcis (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1C0FE6F4: lpmpali (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1C0FDBDE: lpminitm (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1C0FDA21: lpminit (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BCAC448: nau_viat (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BCA54CB: nau_gettab (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BCA3A98: nau_ini (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BC98CB0: nainit (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BC42C4B: nsnainit (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BC361CF: nsopen (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BC1D635: nscall1 (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BC1C9D7: nscall (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BC5508C: niotns (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BCC500B: nigcall (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BC59633: osncon (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BA45E33: kpuadef (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BB0E5AB: upiini (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BAF01D7: upiah0 (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BA45832: kpuatch (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BAD5D3A: OCIServerAttach (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x806AB6F: HS_oci_start (HS_oci.c:402) =3D=3D20816=3D=3D by 0x806B118: HS_do_OCI_stuff (HS_oci.c:646) =3D=3D20816=3D=3D by 0x804D183: HS_send2HS (HS_thr_out.c:131) =3D=3D20816=3D=3D by 0x804D597: HS_convertandsend (HS_thr_out.c:282) =3D=3D20816=3D=3D by 0x804D84C: HS_out_msg (HS_thr_out.c:423) =3D=3D20816=3D=3D by 0x804DD5E: HS_out_main (HS_thr_out.c:651) =3D=3D20816=3D=3D by 0x804E120: HS_main_out (HS_thr_out.c:831) =3D=3D20816=3D=3D by 0x1C366C6E: pthread_start_thread (manager.c:279) =3D=3D20816=3D=3D by 0x1C47FD09: clone (in /lib/i686/libc-2.2.4.so) =0D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D=3D20816=3D=3D Conditional jump or move depends on uninitialised= value(s) =3D=3D20816=3D=3D at 0x1BC7E394: ztcrseed3 (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BCDEAF5: ztvopepad (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BCDEA0A: ztvope (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BE07D63: kzsrepw (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BABADB1: kpu8lgn (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BAB6BD8: kpuauthxa (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BAB60C4: kpuauth (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BAD5E27: OCISessionBegin (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x806AD8A: HS_oci_start (HS_oci.c:463) =3D=3D20816=3D=3D by 0x806B118: HS_do_OCI_stuff (HS_oci.c:646) =3D=3D20816=3D=3D by 0x804D183: HS_send2HS (HS_thr_out.c:131) =3D=3D20816=3D=3D by 0x804D597: HS_convertandsend (HS_thr_out.c:282) =3D=3D20816=3D=3D by 0x804D84C: HS_out_msg (HS_thr_out.c:423) =3D=3D20816=3D=3D by 0x804DD5E: HS_out_main (HS_thr_out.c:651) =3D=3D20816=3D=3D by 0x804E120: HS_main_out (HS_thr_out.c:831) =3D=3D20816=3D=3D by 0x1C366C6E: pthread_start_thread (manager.c:279) =3D=3D20816=3D=3D by 0x1C47FD09: clone (in /lib/i686/libc-2.2.4.so) =0D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =0D =3D=3D20816=3D=3D Conditional jump or move depends on uninitialised= value(s) =3D=3D20816=3D=3D at 0x1BCE5741: CMP_Compare (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BCE6699: CMP_ModularReduce (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BCE324E: Alg_ComputeModQ_GHash (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BC852C9: A_X931RandomGenerateBytes (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BC7E496: ztcrandom (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BCDEB18: ztvopepad (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BCDEA0A: ztvope (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BE07D63: kzsrepw (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BABADB1: kpu8lgn (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BAB6BD8: kpuauthxa (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BAB60C4: kpuauth (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x1BAD5E27: OCISessionBegin (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D20816=3D=3D by 0x806AD8A: HS_oci_start (HS_oci.c:463) =3D=3D20816=3D=3D by 0x806B118: HS_do_OCI_stuff (HS_oci.c:646) =3D=3D20816=3D=3D by 0x804D183: HS_send2HS (HS_thr_out.c:131) =3D=3D20816=3D=3D by 0x804D597: HS_convertandsend (HS_thr_out.c:282) =3D=3D20816=3D=3D by 0x804D84C: HS_out_msg (HS_thr_out.c:423) =3D=3D20816=3D=3D by 0x804DD5E: HS_out_main (HS_thr_out.c:651) =3D=3D20816=3D=3D by 0x804E120: HS_main_out (HS_thr_out.c:831) =3D=3D20816=3D=3D by 0x1C366C6E: pthread_start_thread (manager.c:279) =3D=3D20816=3D=3D by 0x1C47FD09: clone (in /lib/i686/libc-2.2.4.so) This email and any files transmitted with it are confidential and intended= solely for the use of the individual or entity to which they are= addressed. If you have received this email in error, please notify the= system manager. Please note that any views or opinions presented in this= email are solely those of the author and do not necessarily represent= those of the company. Finally, the recipient should check this email and= any attachments for the presence of viruses. The company accepts no= liability for any damage caused by any virus transmitted by this email. |
|
From: Robert W. <rj...@du...> - 2005-04-06 18:12:19
|
As well as the glibc stuff, there's also VALGRIND_PRINTF_BACKTRACE, which only gets invoked when you're running under Valgrind and converts backtrace information to source file/line number information, if it can. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Igmar P. <mai...@jd...> - 2005-04-06 17:39:43
|
> what have I done wrong, I followed the INSTALL file instructions .... > what do you need from me ??? .... Since you're seem to be using a recent gcc : does recompiling with --disable-pie help ? Regards, Igmar |
|
From: John R.
|
>>>http://www.gnu.org/software/libc/manual/html_node/Backtraces.html#Backtraces > > size_t size = backtrace(stack, BT_SIZE); > > Dl_info info; > for (size_t i = skip; i < size; ++i) { > if (dladdr(stack[i], &info) != 0) { > char buf[256]; > size_t len = sizeof(buf); > int status = 0; > result.add(String::format("{0} {1} [0x{2:X}]", args(info.dli_fname, > abi::__cxa_demangle(info.dli_sname, buf, &len, &status), stack[i]))); > } else > result.add(String::format("0x{0:X}", args(stack[i]))); > } For cases where the in-memory symbol tables are not enough, but the on-disk symbol tables are better: [Redirect the output to a file, if necessary.] #include <stdio.h> #include <stdlib.h> #include <unistd.h> char str[100+4096]; char path[4096]; path[readlink("/proc/self/exe", path, -1+ sizeof(path))] = '\0'; sprintf(str, "echo 'bt\ndetach\nquit\n' | gdb -batch -x /dev/stdin %s %d\n", path, (int)getpid() ); system(str); -- John Reiser, jreiser@BitWagon.com |
|
From: robert s. <bo...@ap...> - 2005-04-06 16:58:02
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> it was built with gcc-3.4.3<br> was built on a machine with these specs: (no kidding .... )<br> <br> [bobs@apox5 /data/valgrind-2.4.0]: uname -a<br> Linux apox5 <font color="#ff0000"><b>2.4.20-6smp</b></font> #1 SMP Thu Feb 27 09:59:40 EST 2003 i686 i686 i386 GNU/Linux<br> <br> >file /home/bobs/i386/bin2/bin/valgrind<br> /home/bobs/i386/bin2/bin/valgrind: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for <font color="#ff0000"><b>GNU/Linux 2.2.5,</b></font> statically linked, not stripped<br> <pre class="moz-signature" cols="72"><b>note weird system type!</b> [bobs@apox5 /data/valgrind-2.4.0]: /home/bobs/i386/bin2/bin/valgrind <font color="#ff0000"><b>Segmentation fault (core dumped)</b></font> what have I done wrong, I followed the INSTALL file instructions .... what do you need from me ??? .... -- Robert Somerville Seismic Application Programmer, B.Sc.(Geophysics) Apoterra Seismic Processing Ltd. Suite 2210 144-4th Ave S.W. Calgary, Alberta, Canada T2P 3N4 403-261-0681 (office) 403-261-0690 (fax) </pre> </body> </html> |
|
From: Christian P. <tr...@ge...> - 2005-04-06 15:52:25
|
On Wednesday 06 April 2005 3:16 pm, Christian Parpart wrote: > On Wednesday 06 April 2005 2:49 pm, Michael Renzmann wrote: > > Hi. > > > > Christian Parpart wrote: > > > My goal is to generate my own stacktrace within my program, > > > > You should have a look at: > > http://www.gnu.org/software/libc/manual/html_node/Backtraces.html#Backt= ra > >ce s > > That - obviousely - saves me alot of time :) > > Lets see how I can integrate this. Although, I'm very curious what the li= bc > sources will tell me soon :) #include <cxxabi.h> #include <execinfo.h> #define GNU_SOURCE #include <dlfcn.h> TStringArray getCallTrace(int skip =3D 0) { TStringArray result; const int BT_SIZE =3D 256; void *stack[BT_SIZE]; size_t size =3D backtrace(stack, BT_SIZE); Dl_info info; for (size_t i =3D skip; i < size; ++i) { if (dladdr(stack[i], &info) !=3D 0) { char buf[256]; size_t len =3D sizeof(buf); int status =3D 0; result.add(String::format("{0} {1} [0x{2:X}]", args(info.dli_fn= ame, abi::__cxa_demangle(info.dli_sname, buf, &len, &status), st= ack[i]))); } else result.add(String::format("0x{0:X}", args(stack[i]))); } return result; } Just to share my experiences - This function generates a backtrace using=20 the backtrace() function and reformats each calling function using=20 __cxa_demangle() (GNU C++ ABI function) and puts everything into a vector. I call this function in my exception constructor, so, that when I catch som= e,=20 I can do the following: catch (const TException& e) { // ... FServer->logger().debug("Call Trace:"); for (int i =3D 0, k =3D e.callTrace().size(); i < k; ++i) FServer->logger().debug(String::format("[{0}] {1}", args(i, e.callT= race()[i]))); } That's really nice. Thanks. Regards, Christian Parpart. =2D-=20 Netiquette: http://www.ietf.org/rfc/rfc1855.txt 17:44:24 up 14 days, 6:50, 0 users, load average: 0.52, 0.60, 0.41 |
|
From: Fred S. <fr...@co...> - 2005-04-06 15:35:53
|
I'm getting a ton of "uninitialized memory" errors from deep down inside Oracle's OCI libraries. I'm trying to generate suppressions for them, but valgrind seems to blow right past them without letting me enter anything. Here's an excerpt from my most recent run: =0D =3D=3D12512=3D=3D Thread 4: =3D=3D12512=3D=3D Conditional jump or move depends on uninitialised= value(s) =3D=3D12512=3D=3D at 0x1C0FAA79: lmmmalloc (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D12512=3D=3D by 0x1C154390: lmmcis (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D12512=3D=3D by 0x1C0FE6F4: lpmpali (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D12512=3D=3D by 0x1C0FDBDE: lpminitm (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D12512=3D=3D by 0x1C0FDA21: lpminit (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D12512=3D=3D by 0x1BCAC448: nau_viat (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D12512=3D=3D by 0x1BCA54CB: nau_gettab (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D12512=3D=3D by 0x1BCA3A98: nau_ini (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D12512=3D=3D by 0x1BC98CB0: nainit (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D12512=3D=3D by 0x1BC42C4B: nsnainit (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D12512=3D=3D by 0x1BC361CF: nsopen (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D12512=3D=3D by 0x1BC1D635: nscall1 (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D12512=3D=3D by 0x1BC1C9D7: nscall (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D12512=3D=3D by 0x1BC5508C: niotns (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D12512=3D=3D by 0x1BCC500B: nigcall (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D12512=3D=3D by 0x1BC59633: osncon (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D12512=3D=3D by 0x1BA45E33: kpuadef (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D12512=3D=3D by 0x1BB0E5AB: upiini (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D12512=3D=3D by 0x1BAF01D7: upiah0 (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D12512=3D=3D by 0x1BA45832: kpuatch (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D12512=3D=3D by 0x1BAD5D3A: OCIServerAttach (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D12512=3D=3D by 0x806AB6F: HS_oci_start (HS_oci.c:402) =3D=3D12512=3D=3D by 0x806B118: HS_do_OCI_stuff (HS_oci.c:646) =3D=3D12512=3D=3D by 0x804D183: HS_send2HS (HS_thr_out.c:131) =3D=3D12512=3D=3D by 0x804D597: HS_convertandsend (HS_thr_out.c:282) =3D=3D12512=3D=3D by 0x804D84C: HS_out_msg (HS_thr_out.c:423) =3D=3D12512=3D=3D by 0x804DD5E: HS_out_main (HS_thr_out.c:651) =3D=3D12512=3D=3D by 0x804E120: HS_main_out (HS_thr_out.c:831) =3D=3D12512=3D=3D by 0x1C366C6E: pthread_start_thread (manager.c:279) =3D=3D12512=3D=3D by 0x1C47FD09: clone (in /lib/i686/libc-2.2.4.so) =3D=3D12512=3D=3D =3D=3D12512=3D=3D ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ---- =3D=3D12512=3D=3D <=3D=3D=3D=3D=3D=3D=3D I never see= this one because it doesn't pause here. =3D=3D12512=3D=3D Conditional jump or move depends on uninitialised= value(s) =3D=3D12512=3D=3D at 0x1C0FAAA7: lmmmalloc (in /home/oracle/OraHome1/lib/libclntsh.so.9.0) =3D=3D12512=3D=3D by 0x1C154390: lmmcis (in /home/oracle/OraHome1/lib/libclntsh.so.9. This email and any files transmitted with it are confidential and intended= solely for the use of the individual or entity to which they are= addressed. If you have received this email in error, please notify the= system manager. Please note that any views or opinions presented in this= email are solely those of the author and do not necessarily represent= those of the company. Finally, the recipient should check this email and= any attachments for the presence of viruses. The company accepts no= liability for any damage caused by any virus transmitted by this email. |
|
From: Christian P. <tr...@ge...> - 2005-04-06 13:16:18
|
On Wednesday 06 April 2005 2:49 pm, Michael Renzmann wrote: > Hi. > > Christian Parpart wrote: > > My goal is to generate my own stacktrace within my program, > > You should have a look at: > http://www.gnu.org/software/libc/manual/html_node/Backtraces.html#Backtra= ce >s That - obviousely - saves me alot of time :) Lets see how I can integrate this. Although, I'm very curious what the libc= =20 sources will tell me soon :) Regards, Christian Parpart. =2D-=20 Netiquette: http://www.ietf.org/rfc/rfc1855.txt 15:14:38 up 14 days, 4:21, 0 users, load average: 0.23, 0.17, 0.16 |
|
From: Christian P. <tr...@ge...> - 2005-04-06 13:06:22
|
On Wednesday 06 April 2005 2:42 pm, Nicholas Nethercote wrote:
> On Wed, 6 Apr 2005, Christian Parpart wrote:
> > I wonder how valgrind does this. Well, I already took a look into
> > stacktrace.c of SVN trunk's repository - but (how wonder) this is very
> > valgrind specific.
>
> I don't think it's very Valgrind-specific. Basically you just need to
> find the return addresses on the stack, and use those addresses to look up
> debugging information (which you have to read separately) to find the
> function names. That's pretty much what the code in stacktrace.c does.
Of course, this is not valgrind-specific. BUT I know that valgrind is creat=
ing=20
stack traces on the fly as well. Except, that it doesn't to for itself but=
=20
for its guest process (the one to be observed).
In the kernel sources, I actually found, that they're using something like=
=20
this [arch/x86-64/kernel/traps.c]:
void dump_stack(void) { // ARCH independant
unsigned long dummy;
show_trace(&dummy);
}
void show_trace(unsigned long *stack) { // x86-64 dependant.
// ....
int i =3D 0;
while (((long)stack & (THREAD_SIZE - 1)) !=3D 0) {
unsigned long addr =3D *stack++;
if (__kernel_text_address(addr)) {
i +=3D printk_address(addr);
i +=3D printk(" ");
if (i > 50) {
printk("\n ");
i =3D 0;
}
}
}
printk("\n");
}
__kernel_text_address() returns true in case it got passed an address withi=
n=20
the kernel address space (or any module address space).
printk_address then prints the symbol address, module name and symbolname.
So, I guess I got it (not quite sure yet), but one question remains, how to=
=20
get the symbol names I want the addresses for.
Why do they (in the kernel) something like (((long)stack & (THREAD_SIZE -=20
1)) !=3D 0). How's this adoptable to a userspace process (generically).
demangling isn't a problem. Here I already got some source code (from gcc :=
=2DD)
> > All I know is, that other apps (like ut2004-bin) is doing the same.
>
> Can you find source code for these other apps, for comparison?
I'd be happy if. But at least ut2004-bin is binary-only (no sources).
=2D-=20
Netiquette: http://www.ietf.org/rfc/rfc1855.txt
14:45:35 up 14 days, 3:52, 0 users, load average: 0.13, 0.20, 0.22
|
|
From: Michael R. <val...@no...> - 2005-04-06 12:49:50
|
Hi. Christian Parpart wrote: > My goal is to generate my own stacktrace within my program, You should have a look at: http://www.gnu.org/software/libc/manual/html_node/Backtraces.html#Backtraces In a current project I have a function like this: void stack_print_trace(void) { int num_frames = 0; void *stack[64]; num_frames = backtrace(stack, 64); fprintf(stderr, "stack trace:\n"); backtrace_symbols_fd(stack, num_frames, 2); return; } which is called within the SIGSEGV handler. hth. Bye, Mike |
|
From: Nicholas N. <nj...@cs...> - 2005-04-06 12:42:12
|
On Wed, 6 Apr 2005, Christian Parpart wrote: > I wonder how valgrind does this. Well, I already took a look into stacktrace.c > of SVN trunk's repository - but (how wonder) this is very valgrind specific. I don't think it's very Valgrind-specific. Basically you just need to find the return addresses on the stack, and use those addresses to look up debugging information (which you have to read separately) to find the function names. That's pretty much what the code in stacktrace.c does. > All I know is, that other apps (like ut2004-bin) is doing the same. Can you find source code for these other apps, for comparison? N |
|
From: Christian P. <tr...@ge...> - 2005-04-06 12:33:26
|
Hi,
I wonder how valgrind does this. Well, I already took a look into stacktrac=
e.c=20
of SVN trunk's repository - but (how wonder) this is very valgrind specific.
My goal is to generate my own stacktrace within my program, e.g. when I=20
receive a certain signal (SIGSEGFAULT) or, when a C++ exception is to be=20
instanciated (so the constructor could do this for a better error tracking).
Suppose we've a funktion like this:
std::vector<std::string> getStackTrace() {
std::vector<std::string> stacktrace;
// magic here
return stacktrace;
}
and any function, like this:
void foo() {
if (errorOccured)
printStacktrace("An error just happened", getStackTrace());
}
which would then print out the stack trace up to from top-of-stack (e.g.=20
main()) down to foo().
I'm obviousely *not* able to google for it, as I didn't find any good docs=
=20
about :(
All I know is, that other apps (like ut2004-bin) is doing the same.
I'd be really very very happy if someone could point out me to the right=20
direction here.
p.s.: my arch: amd64/linux and x86/linux.
Thanks in advance,
Christian Parpart.
=2D-=20
Netiquette: http://www.ietf.org/rfc/rfc1855.txt
14:26:13 up 14 days, 3:32, 0 users, load average: 0.05, 0.12, 0.14
|
|
From: Tom H. <to...@co...> - 2005-04-05 22:08:08
|
In message <6.1.2.0.0.20050405233143.04ac9ec0@192.168.5.6>
Dennis Lubert <pla...@in...> wrote:
> At 23:20 05.04.2005, you wrote:
> >On Tue, 5 Apr 2005, Dennis Lubert wrote:
> >
> >>FAQ 4.4
> >
> >Huh? 4.4 doesn't address this issue.
>
>
> Well in my version (rather recent CVS) :
>
> 4.4 The stack traces given by Memcheck (or another tool) aren't helpful.
> How can I improve them?
>
> If they're not long enough, use --num-callers to make them longer.
>
> "There are no write() calls anywhere in that call trace."
> " Any way to get more detail out of valgrind in cases like this?"
>
> My idea : longer stack trace, lookup matched FAQ 4.4 here...
He could see where write was being called from, so a longer stack
trace wouldn't have been of any help at all. His problem was that
the write was being tail called from pthread_create or something
so that the intermediate rouitne vanished from the stack leading
to confusion.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Dennis L. <pla...@in...> - 2005-04-05 21:34:53
|
At 23:20 05.04.2005, you wrote: >On Tue, 5 Apr 2005, Dennis Lubert wrote: > >>FAQ 4.4 > >Huh? 4.4 doesn't address this issue. Well in my version (rather recent CVS) : 4.4 The stack traces given by Memcheck (or another tool) aren't helpful. How can I improve them? If they're not long enough, use --num-callers to make them longer. "There are no write() calls anywhere in that call trace." " Any way to get more detail out of valgrind in cases like this?" My idea : longer stack trace, lookup matched FAQ 4.4 here... greets Dennis Carpe quod tibi datum est |
|
From: Nicholas N. <nj...@cs...> - 2005-04-05 21:20:42
|
On Tue, 5 Apr 2005, Dennis Lubert wrote: > FAQ 4.4 Huh? 4.4 doesn't address this issue. > At 23:08 05.04.2005, Fred Smith wrote: >> >> ==8217== Syscall param write(buf) points to uninitialised byte(s) >> ==8217== at 0x1C473054: write (in /lib/i686/libc-2.2.4.so) >> ==8217== by 0x804BCC9: HS_start_inthread (HS_runif.c:84) >> ==8217== by 0x804BF17: HS_start_oneif (HS_runif.c:202) >> ==8217== by 0x804C046: HS_start_interfaces (HS_runif.c:238) >> ==8217== by 0x804B706: main (HS_hl7main.c:389) >> ==8217== Address 0x52BFE5AC is on thread 1's stack >> >> But I don't get it. There are no write() calls anywhere in that call trace. Huh? What about the 2nd line? >> The call at line 84 of HS_runif is a call to pthread_create(). I can't see >> anything un-initialized in the parameter list, either. Any way to get more >> detail out of valgrind in cases like this? I'm using RHEL WS 2.1. This is caused by the pthreads library, not your code. You can safely ignore it; just create a suppression for the error. N |
|
From: Paul S. <ps...@no...> - 2005-04-05 21:19:35
|
%% Dennis Lubert <pla...@in...> writes: dl> FAQ 4.4 ITYM 5.4 ... ? -- ------------------------------------------------------------------------------- Paul D. Smith <ps...@no...> HASMAT: HA Software Mthds & Tools "Please remain calm...I may be mad, but I am a professional." --Mad Scientist ------------------------------------------------------------------------------- These are my opinions---Nortel Networks takes no responsibility for them. |
|
From: Dennis L. <pla...@in...> - 2005-04-05 21:12:13
|
FAQ 4.4 At 23:08 05.04.2005, Fred Smith wrote: >I'm getting this: > >==8217== Syscall param write(buf) points to uninitialised byte(s) >==8217== at 0x1C473054: write (in /lib/i686/libc-2.2.4.so) >==8217== by 0x804BCC9: HS_start_inthread (HS_runif.c:84) >==8217== by 0x804BF17: HS_start_oneif (HS_runif.c:202) >==8217== by 0x804C046: HS_start_interfaces (HS_runif.c:238) >==8217== by 0x804B706: main (HS_hl7main.c:389) >==8217== Address 0x52BFE5AC is on thread 1's stack > >But I don't get it. There are no write() calls anywhere in that call >trace. The call at line 84 of HS_runif is a call to pthread_create(). I >can't see anything un-initialized in the parameter list, either. Any way >to get more detail out of valgrind in cases like this? I'm using RHEL WS 2.1. > >Fred >This email and any files transmitted with it are confidential and intended >solely for the use of the individual or entity to which they are >addressed. If you have received this email in error, please notify the >system manager. Please note that any views or opinions presented in this >email are solely those of the author and do not necessarily represent >those of the company. Finally, the recipient should check this email and >any attachments for the presence of viruses. The company accepts no >liability for any damage caused by any virus transmitted by this email. Carpe quod tibi datum est |
|
From: Fred S. <fr...@co...> - 2005-04-05 21:02:57
|
I'm getting this: =0D =3D=3D8217=3D=3D Syscall param write(buf) points to uninitialised byte(s) =3D=3D8217=3D=3D at 0x1C473054: write (in /lib/i686/libc-2.2.4.so) =3D=3D8217=3D=3D by 0x804BCC9: HS_start_inthread (HS_runif.c:84) =3D=3D8217=3D=3D by 0x804BF17: HS_start_oneif (HS_runif.c:202) =3D=3D8217=3D=3D by 0x804C046: HS_start_interfaces (HS_runif.c:238) =3D=3D8217=3D=3D by 0x804B706: main (HS_hl7main.c:389) =3D=3D8217=3D=3D Address 0x52BFE5AC is on thread 1's stack =0D But I don't get it. There are no write() calls anywhere in that call trace. The call at line 84 of HS_runif is a call to pthread_create(). I can't see anything un-initialized in the parameter list, either. Any way to get more detail out of valgrind in cases like this? I'm using RHEL WS 2.1. =0D Fred This email and any files transmitted with it are confidential and intended= solely for the use of the individual or entity to which they are= addressed. If you have received this email in error, please notify the= system manager. Please note that any views or opinions presented in this= email are solely those of the author and do not necessarily represent= those of the company. Finally, the recipient should check this email and= any attachments for the presence of viruses. The company accepts no= liability for any damage caused by any virus transmitted by this email. |
|
From: Hanifa W. <Am...@fs...> - 2005-04-05 04:59:29
|
Hello, willing enough to dull his wits to the extent of accepting the Stone walls do not a prison make, point out to M. de Cussy that the share offered was too small. F situation. The Arabella was no longer in case to put to sea; the was your business then? M. de Rivarol, intrigued by his mirth, scowled upon him Soon his cane was reduced, to splinters by his violence. You kno String him up from the yardarm, he cried, his deep voice harsh himself ashore and his ships in safe shelter. He wondered a litt when it suited him, tended his geraniums and smoked his pipe on t thick black hair, once so sedulously curled, hung now in a lank, quarter-deck with his lordship in attendance - as you would expec evenings, when men of spirit were rallying to the Protestant Rivarol, as down from a thistle by the winds of autumn. The Gene Have a nice day. |
|
From: Christian P. <tr...@ge...> - 2005-04-02 22:40:34
|
On Saturday 02 April 2005 8:45 pm, Dennis Lubert wrote: > Am Samstag, den 02.04.2005, 13:02 +0200 schrieb Christian Parpart: > > that's strange. > > I just compiled valgrind-2.4.0 on a new chroot (32bit-only) environment > > on my amd64. I got a segfault, so I just remerged it again. But it > > failed. That may be because I first had default compiler (gcc3.3) > > installed and now have gcc3.4. however, it complains about a const-ness > > problem: > > [snisnap] > > > Any hints? > > I just tried building valgrind 2.4 from CVS with gcc 3.4.3 and 4.0CVS > and it didnt complain bout anything, maybe it works with the valgrind > cvs for you too... just a hint... You don't have to believe me, but it compiles now. No clue why. I could now= even tell you where exactly gcc aborted, and how I fixed it. however, I co= mplete recompile (using emerge) of 2.4.0 on gcc3.4 worked fine now. My mach= ine's just too strange. However, the segfault problem persists (for valgrind2.4.0) but I just notic= ed, that the gentoo griffon26 (for my luck) noticed this as well, though, t= his is not my stupid box raising it alone ;) battousai libswl-0.4 # emerge -pv '=3Ddev-util/valgrind-2.4.0' These are the packages that I would merge, in order: Calculating dependencies !!! All ebuilds that could satisfy "=3Ddev-util/valgrind-2.4.0" have been m= asked. !!! One of the following masked packages is required to complete your reque= st: =2D dev-util/valgrind-2.4.0 (masked by: package.mask) # Maurice van der Pot <gri...@ge...> (02 Apr 2005) # Segfaults on everything. Masking until I get some time to # fix it, which should be in a couple of days. 2.2. works just fine in my 32bit chroot environment :D Regards, Christian Parpart. =2D-=20 Netiquette: http://www.ietf.org/rfc/rfc1855.txt 00:35:22 up 10 days, 13:41, 0 users, load average: 0.37, 0.32, 0.28 |
|
From: Dennis L. <pla...@in...> - 2005-04-02 18:47:00
|
Am Samstag, den 02.04.2005, 13:02 +0200 schrieb Christian Parpart: > that's strange. > I just compiled valgrind-2.4.0 on a new chroot (32bit-only) environment on my > amd64. I got a segfault, so I just remerged it again. But it failed. That may > be because I first had default compiler (gcc3.3) installed and now have > gcc3.4. however, it complains about a const-ness problem: [snisnap] > > Any hints? I just tried building valgrind 2.4 from CVS with gcc 3.4.3 and 4.0CVS and it didnt complain bout anything, maybe it works with the valgrind cvs for you too... just a hint... greets Dennis |
|
From: Dennis L. <pla...@tz...> - 2005-04-02 13:19:19
|
Am Samstag, den 02.04.2005, 02:21 +0100 schrieb Julian Seward: > Greetings, all. > > I'm currently mashing Memcheck/Addrcheck internals about. I'd > like to get rid of the --sloppy-malloc=yes flag if possible. > Having to check the flag at every allocation wastes time in > allocation-intensive programs, and I don't believe anybody > really uses it. > > So, does anybody use this flag? I used it from time to time to cope with some messed up libraries, but havent thought about it for over a year or so now, so I personally think noone really needs it, since valgrind is an error detection program and not a program to run programs that are full of errors... greets Dennis PS: I dont know much of the internals of valgrind, but for similar cases where I have runtime flags, I use function pointers and load them with different functions so I need to check the flag only once... |
|
From: Maurice v. d. P. <gri...@ge...> - 2005-04-02 11:46:08
|
Is there a bug report for this one already? I'm experiencing the same=20 problem. --disable-pie fixes it. Maurice. --=20 Maurice van der Pot Gentoo Linux Developer gri...@ge... http://www.gentoo.org Creator of BiteMe! gri...@kf... http://www.kfk4ever.com |
|
From: Christian P. <tr...@ge...> - 2005-04-02 11:02:35
|
that's strange. I just compiled valgrind-2.4.0 on a new chroot (32bit-only) environment on = my=20 amd64. I got a segfault, so I just remerged it again. But it failed. That m= ay=20 be because I first had default compiler (gcc3.3) installed and now have=20 gcc3.4. however, it complains about a const-ness problem: if i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind=20 =2DI../coregrind -I.. -I../coregrind/x86 -I../coregrind/x86=20 =2DI../coregrind/linux -I../coregrind/x86-linux -I../include -I../include=20 =2DI../include/x86 -I../include/linux -I../include/x86-linux=20 =2DDVG_LIBDIR=3D"\"/usr/lib/valgrind"\" -I./demangle -DKICKSTART_BASE=3D0xb= 0000000=20 =2DDVG_PLATFORM=3D"\"x86-linux"\" -Winline -Wall -Wshadow -O -g=20 =2Dmpreferred-stack-boundary=3D2 -DELFSZ=3D32 -fpie -nopie -O0 -ggdb3 -pipe= =20 =2Dfno-pie -Wno-long-long -MT stage2-vg_memory.o -MD -MP -MF=20 ".deps/stage2-vg_memory.Tpo" -c -o stage2-vg_memory.o `test -f 'vg_memory.c= '=20 || echo './'`vg_memory.c; \ then mv -f ".deps/stage2-vg_memory.Tpo" ".deps/stage2-vg_memory.Po"; else r= m=20 =2Df ".deps/stage2-vg_memory.Tpo"; exit 1; fi vg_memory.c: In function `vgPlain_unmap_range': vg_memory.c:161: error: initializer element is not constant vg_memory.c: In function `vgPlain_map_file_segment': vg_memory.c:327: error: initializer element is not constant vg_memory.c: In function `vgPlain_mprotect_range': vg_memory.c:482: error: initializer element is not constant vg_memory.c: In function `vgPlain_find_map_space': vg_memory.c:527: error: initializer element is not constant make[4]: *** [stage2-vg_memory.o] Error 1 battousai valgrind-2.4.0 # gcc -v Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.3-20050110/specs Configured=20 with: /var/tmp/portage/gcc-3.4.3.20050110-r1/work/gcc-3.4.3/configure=20 =2D-enable-version-specific-runtime-libs --prefix=3D/usr=20 =2D-bindir=3D/usr/i686-pc-linux-gnu/gcc-bin/3.4.3-20050110=20 =2D-includedir=3D/usr/lib/gcc/i686-pc-linux-gnu/3.4.3-20050110/include=20 =2D-datadir=3D/usr/share/gcc-data/i686-pc-linux-gnu/3.4.3-20050110=20 =2D-mandir=3D/usr/share/gcc-data/i686-pc-linux-gnu/3.4.3-20050110/man=20 =2D-infodir=3D/usr/share/gcc-data/i686-pc-linux-gnu/3.4.3-20050110/info=20 =2D-with-gxx-include-dir=3D/usr/lib/gcc/i686-pc-linux-gnu/3.4.3-20050110/in= clude/g++-v3=20 =2D-host=3Di686-pc-linux-gnu --disable-altivec --enable-nls=20 =2D-without-included-gettext --with-system-zlib --disable-checking=20 =2D-disable-werror --disable-libunwind-exceptions --disable-multilib=20 =2D-disable-libgcj --enable-languages=3Dc,c++,f77 --enable-shared=20 =2D-enable-threads=3Dposix --enable-__cxa_atexit --enable-clocale=3Dgnu Thread model: posix gcc version 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110-r1,=20 ssp-3.4.3.20050110-0, pie-8.7.7) Any hints? Thanks, Christian Parpart. =2D-=20 Netiquette: http://www.ietf.org/rfc/rfc1855.txt 12:57:52 up 10 days, 2:04, 0 users, load average: 0.26, 0.18, 0.07 |
|
From: nithya p. <vis...@ya...> - 2005-04-02 10:11:50
|
dear team,
we have the .aux and .hp files generated when we comment out the following two
lines in massif/ms_main.c:
VG_(unlink)(hp_file);
VG_(unlink)(aux_file);
the following are my doubts.
1.why are multiple .hp and .aux files generated.ie if i run valgrind once , i get nearly 4 to 5 .aux files.
2.how to interpret the values specified in the .aux files.
3.how to plot a graph for both the stack and heap memory usage using the above values
thanks in advance
nithya
---------------------------------
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site! |