Menu
▾
▴
valgrind-users
|
From: Dan K. <da...@ke...> - 2003-05-11 19:49:29
|
Hi, I'm using valgrind 1.9.6 on redhat 8.0 with OpenOffice.
It seems to work fine with no options, but if I turn on
--gdb-attach=yes, I don't get what I expect. On the
first error, it asks me nicely if I want to run gdb,
and it does start gdb, but here's what I see:
==18736== ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- y
==18736== starting GDB with cmd: /usr/bin/gdb -nw /proc/18736/exe 18736
GNU gdb Red Hat Linux (5.2.1-4)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(no debugging symbols found)...
Attaching to program: /opt/OpenOffice.org644/program/soffice.bin, process 18736
Reading symbols from /usr/local/lib/valgrind/vgskin_memcheck.so...done.
Loaded symbols for /usr/local/lib/valgrind/vgskin_memcheck.so
Reading symbols from /usr/local/lib/valgrind/valgrind.so...done.
Loaded symbols for /usr/local/lib/valgrind/valgrind.so
Reading symbols from /opt/OpenOffice.org644/program/libvcl644li.so...done.
Loaded symbols for /opt/OpenOffice.org644/program/libvcl644li.so
... etc etc ...
Reading symbols from /opt/OpenOffice.org644/program/libsal.so.3...done.
Loaded symbols for /opt/OpenOffice.org644/program/libsal.so.3
Reading symbols from /usr/X11R6/lib/libXext.so.6...done.
Loaded symbols for /usr/X11R6/lib/libXext.so.6
[1]+ Stopped ./soffice-valgrind.sh
If I then do a fg, it seems to continue, but things are all screwed up.
gdb goes away as soon as it finishes loading up:
vg_do_syscall3 (syscallno=4294966784, arg1=18738, arg2=0, arg3=0)
at vg_mylibc.c:92
92 }
(gdb) ==18736==
==18736== GDB has detached. Valgrind regains control. We continue.
and the app continues on, seemingly in the background, while I'm
dumped back to the shell. Very odd.
Any suggestions?
Thanks,
Dan
--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
|
|
From: Julian S. <js...@ac...> - 2003-05-11 22:28:48
Attachments:
errnofix.txt
|
Hi. First off, I think OpenOffice is an important project and am pleased to hear someone is valgrinding it. OO is my biggest, most hairy test case. If it's possible, I'd like to help the OOo developers be in the position where they routinely valgrindify OOo, in the same way that the KDE and Gnome folks use it routinely. I don't a RH8 box to repro this on. But I have just tried gdb attach/detach on SuSE 8.2 on the OOo 1.0.2 they supply, and that works fine using the valgrind cvs head. I did it a bit different from you, perhaps: LD_LIBRARY_PATH=/opt/OpenOffice.org/program \ ./Inst/bin/valgrind -v -v --skin=addrcheck \ --gdb-attach=yes /opt/OpenOffice.org/program/soffice.bin I did all that directly on the command line, no shell script or anything. Perhaps your shell script ./soffice-valgrind.sh is causing a problem? Can you try something equivalent to the above? I fixed a threading problem that 1.9.6 has with glibc >= 2.3.2, which caused it to mis-handle errno, but IIRC RH8 is glibc-2.3.1 and the errno problems didn't seem to afflict it. Nevertheless I attach a patch which fixes the problem and you should apply it to your 1.9.6. It'll be rolled into 1.9.7. Let me know the outcome of the above. The following is a question re OO on V. With the help of Michael Meeks at Ximian, I did manage to build from source various cvs branches of OO (cws_srx644_ooo11beta, in the end) and valgrinded them. What I noticed was that (1) the number of mallocs/frees reported by V was surprisingly low, compared with 1.0.2, and (2) all the buffer-overrun errors had disappeared. And so I wondered if OO had moved to using some kind of internal allocator which V cannot 'see' ? Alternatively of course all those bugs have been fixed. J On Sunday 11 May 2003 9:13 pm, Dan Kegel wrote: > Hi, I'm using valgrind 1.9.6 on redhat 8.0 with OpenOffice. > It seems to work fine with no options, but if I turn on > --gdb-attach=yes, I don't get what I expect. On the > first error, it asks me nicely if I want to run gdb, > and it does start gdb, but here's what I see: > > ==18736== ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- y > ==18736== starting GDB with cmd: /usr/bin/gdb -nw /proc/18736/exe 18736 > GNU gdb Red Hat Linux (5.2.1-4) > Copyright 2002 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are welcome to change it and/or distribute copies of it under certain > conditions. Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-redhat-linux"... > (no debugging symbols found)... > Attaching to program: /opt/OpenOffice.org644/program/soffice.bin, process > 18736 Reading symbols from > /usr/local/lib/valgrind/vgskin_memcheck.so...done. Loaded symbols for > /usr/local/lib/valgrind/vgskin_memcheck.so > Reading symbols from /usr/local/lib/valgrind/valgrind.so...done. > Loaded symbols for /usr/local/lib/valgrind/valgrind.so > Reading symbols from /opt/OpenOffice.org644/program/libvcl644li.so...done. > Loaded symbols for /opt/OpenOffice.org644/program/libvcl644li.so > ... etc etc ... > Reading symbols from /opt/OpenOffice.org644/program/libsal.so.3...done. > Loaded symbols for /opt/OpenOffice.org644/program/libsal.so.3 > Reading symbols from /usr/X11R6/lib/libXext.so.6...done. > Loaded symbols for /usr/X11R6/lib/libXext.so.6 > > [1]+ Stopped ./soffice-valgrind.sh > > If I then do a fg, it seems to continue, but things are all screwed up. > gdb goes away as soon as it finishes loading up: > > vg_do_syscall3 (syscallno=4294966784, arg1=18738, arg2=0, arg3=0) > at vg_mylibc.c:92 > 92 } > (gdb) ==18736== > ==18736== GDB has detached. Valgrind regains control. We continue. > > and the app continues on, seemingly in the background, while I'm > dumped back to the shell. Very odd. > > Any suggestions? > > Thanks, > Dan |
|
From: Troels W. H. <tr...@th...> - 2003-05-12 07:44:01
|
> I fixed a threading problem that 1.9.6 has with glibc >= 2.3.2, > which caused it to mis-handle errno, but IIRC RH8 is glibc-2.3.1 > and the errno problems didn't seem to afflict it. RH8 ships with glibc 2.3.1, but 2.3.2 is available as a security update, so many people probably have 2.3.2. https://rhn.redhat.com/errata/RHSA-2003-089.html -- Troels |
|
From: Dan K. <da...@ke...> - 2003-05-12 07:56:05
|
Troels Walsted Hansen wrote: >>I fixed a threading problem that 1.9.6 has with glibc >= 2.3.2, >>which caused it to mis-handle errno, but IIRC RH8 is glibc-2.3.1 >>and the errno problems didn't seem to afflict it. > > > RH8 ships with glibc 2.3.1, but 2.3.2 is available as a security update, > so many people probably have 2.3.2. > > https://rhn.redhat.com/errata/RHSA-2003-089.html > [dank@krunch dank]$ cat /etc/issue Red Hat Linux release 8.0 (Psyche) Kernel \r on an \m [dank@krunch dank]$ rpm -q -a | grep glibc glibc-2.2.93-5 glibc-devel-2.2.93-5 glibc-common-2.2.93-5 glibc-kernheaders-2.4-7.20 I don't think my system is updated. Thus I suspect Red Hat 8 ships with a prerelease version of glibc 2.3.0 called 2.2.93. (And since my problem happens on rh7.2 as well, I don't think the errno handling is the problem.) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 |
|
From: Dan K. <da...@ke...> - 2003-05-12 05:25:06
|
Julian Seward (jseward at acm.org) wrote: > Hi. First off, I think OpenOffice is an important project > and am pleased to hear someone is valgrinding it. OO is my > biggest, most hairy test case. If it's possible, I'd like to > help the OOo developers be in the position where they routinely > valgrindify OOo, in the same way that the KDE and Gnome folks > use it routinely. Excellent! I'm hoping to use it quickly in the next few days to help make OpenOffice 1.1 beta more solid. I don't know if the openoffice developers are using it yet; I'm just a gadfly who got a bee in his bonnet about a backlog of untriaged bugs in the openoffice bug tracking system, and jumped in to help sort through them and mark the interesting ones for the developers to work on. > I don't a RH8 box to repro this on. But I have just tried > gdb attach/detach on SuSE 8.2 on the OOo 1.0.2 they supply, > and that works fine using the valgrind cvs head. I did it a > bit different from you, perhaps: > > LD_LIBRARY_PATH=/opt/OpenOffice.org/program \ > ./Inst/bin/valgrind -v -v --skin=addrcheck \ > --gdb-attach=yes /opt/OpenOffice.org/program/soffice.bin > > I did all that directly on the command line, no shell script > or anything. Perhaps your shell script ./soffice-valgrind.sh > is causing a problem? Can you try something equivalent to the > above? Thanks for that nice short line. (I had been clumsily editing the soffice script without bothering to understand it.) However, I get the same results with that as with my script. Also, your errno patch didn't have any impact on the strange problem I had running valgrind 1.9.6 on Red Hat 8, just as you expected. The good news is, I verified that valgrind 1.9.6 on Red Hat 7.2 does run openoffice1.1beta just fine. I believe I'm unstuck now, and will continue with OO on valgrind next chance I get. > The following is a question re OO on V. With the help of Michael > Meeks at Ximian, I did manage to build from source various cvs > branches of OO (cws_srx644_ooo11beta, in the end) and valgrinded > them. What I noticed was that (1) the number of mallocs/frees > reported by V was surprisingly low, compared with 1.0.2, > and (2) all the buffer-overrun errors had disappeared. And so > I wondered if OO had moved to using some kind of internal > allocator which V cannot 'see' ? Alternatively of course all > those bugs have been fixed. No idea - but I'll pass the question on to de...@op.... - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 |
|
From: Dan K. <da...@ke...> - 2003-05-12 07:29:42
|
Dan Kegel wrote: > The good news is, I verified that valgrind 1.9.6 on Red Hat 7.2 > does run openoffice1.1beta just fine. > I believe I'm unstuck now, and will continue with OO on valgrind > next chance I get. Damn, damn, damn. Nope. Here's the deal: even on red hat 7.2, only the first couple of errors invoke gdb properly. After that, when gdb is invoked, something is wrong with stdin; gdb thinks it's at EOF. Think openoffice is closing stdin? For what it's worth, here's the bug I'm really going after: http://www.openoffice.org/project/www/issues/show_bug.cgi?id=14046 To reproduce it, just load the file FR0453p.doc into ooo1.1beta1 or the later snapshot build 644_m11. Without valgrind, you have to click on the first page, click Format/arrange/send to back (or any of the other arrange commands, probably), then undo, to trigger the crash. With Valgrind, I get ==6614== Invalid memory access of size 2 ==6614== at 0x41020329: (within /usr/X11R6/lib/libX11.so.6.2) ==6614== by 0x4101F934: (within /usr/X11R6/lib/libX11.so.6.2) ==6614== by 0x4102043A: XSubtractRegion (in /usr/X11R6/lib/libX11.so.6.2) ==6614== by 0x4102049B: XXorRegion (in /usr/X11R6/lib/libX11.so.6.2) ==6614== Address 0x42C1D970 is 0 bytes after a block of size 16 alloc'd ==6614== at 0x40150E99: realloc (vg_clientfuncs.c:276) ==6614== by 0x4101A78A: (within /usr/X11R6/lib/libX11.so.6.2) ==6614== by 0x4101AEB7: XPolygonRegion (in /usr/X11R6/lib/libX11.so.6.2) ==6614== by 0x40590A17: SalGraphics::DrawPolyPolygon(unsigned long, unsigned long const*, SalPoint const**, OutputDevice const*) (in /home/dank/opt/OpenOffice.org1.1Beta/program/libvcl644li.so) ==6614== as soon as the file finishes loading; you don't even have to do the send-to-back/undo thing. Saying 'y' to valgrind at that point starts gdb, but it goes haywire as if the keyboard isn't really attached anymore. I'd like to get a backtrace with gdb there. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 |
|
From: Julian S. <js...@ac...> - 2003-05-12 07:57:06
|
Dan
Attached is a patch which allows you to change stdin to whatever
you like, if you thing V is closing it.
J
------------------------------------------------------------------
[Valgrind-users] Patch to make debugging curses programs easier
Date: Sun May 11 18:31:24 2003
From: Sami Liedes <sl...@cc...>
To: val...@li...
I found the following simple changes helpful in using Valgrind to
debug curses programs with --gdb-attach=yes.
I'd be happy to know if someone has found an easier way to use
--gdb-attach=yes with curses programs; if not, this patch might be
useful for others too. With it it's possible to read the Y/N for the
"attach gdb" question from any file descriptor (--input=fd=<n>). The
--gdb-command=<command> option allows e.g. using a script to start gdb
in an xterm (or using openvt).
Attached patch against 1.9.6.
Sami
diff -ur valgrind-1.9.6/coregrind/vg_errcontext.c
valgrind-1.9.6-cursespatch/coregrind/vg_errcontext.c
--- valgrind-1.9.6/coregrind/vg_errcontext.c 2003-01-28 21:59:35.000000000
+0200
+++ valgrind-1.9.6-cursespatch/coregrind/vg_errcontext.c 2003-05-10
18:46:47.000000000 +0300
@@ -141,14 +141,14 @@
VG_(getpid)()
);
- res = VG_(read)(0 /*stdin*/, &ch, 1);
+ res = VG_(read)(VG_(clo_input_fd), &ch, 1);
if (res != 1) goto ioerror;
/* res == 1 */
if (ch == '\n') return False;
if (ch != 'N' && ch != 'n' && ch != 'Y' && ch != 'y'
&& ch != 'C' && ch != 'c') goto again;
- res = VG_(read)(0 /*stdin*/, &ch2, 1);
+ res = VG_(read)(VG_(clo_input_fd), &ch2, 1);
if (res != 1) goto ioerror;
if (ch2 != '\n') goto again;
diff -ur valgrind-1.9.6/coregrind/vg_include.h
valgrind-1.9.6-cursespatch/coregrind/vg_include.h
--- valgrind-1.9.6/coregrind/vg_include.h 2003-05-05 02:34:22.000000000
+0300
+++ valgrind-1.9.6-cursespatch/coregrind/vg_include.h 2003-05-10
17:57:12.000000000 +0300
@@ -171,6 +171,8 @@
extern Bool VG_(clo_error_limit);
/* Enquire about whether to attach to GDB at errors? default: NO */
extern Bool VG_(clo_GDB_attach);
+/* The command to run as GDB? default: gdb */
+extern Char* VG_(clo_GDB_command);
/* Sanity-check level: 0 = none, 1 (default), > 1 = expensive. */
extern Int VG_(sanity_level);
/* Automatically attempt to demangle C++ names? default: YES */
@@ -205,6 +207,8 @@
extern Int VG_(clo_logfile_fd);
extern Char* VG_(clo_logfile_name);
+/* The file descriptor to read for input. */
+extern Int VG_(clo_input_fd);
/* The number of suppression files specified. */
extern Int VG_(clo_n_suppressions);
/* The names of the suppression files. */
diff -ur valgrind-1.9.6/coregrind/vg_main.c
valgrind-1.9.6-cursespatch/coregrind/vg_main.c
--- valgrind-1.9.6/coregrind/vg_main.c 2003-05-05 03:03:40.000000000 +0300
+++ valgrind-1.9.6-cursespatch/coregrind/vg_main.c 2003-05-10
18:47:35.000000000 +0300
@@ -457,6 +457,7 @@
/* Define, and set defaults. */
Bool VG_(clo_error_limit) = True;
Bool VG_(clo_GDB_attach) = False;
+Char* VG_(clo_GDB_command) = "gdb";
Int VG_(sanity_level) = 1;
Int VG_(clo_verbosity) = 1;
Bool VG_(clo_demangle) = True;
@@ -469,6 +470,7 @@
Int VG_(clo_logfile_fd) = 2;
Char* VG_(clo_logfile_name) = NULL;
+Int VG_(clo_input_fd) = 0; /* stdin */
Int VG_(clo_n_suppressions) = 0;
Char* VG_(clo_suppressions)[VG_CLO_MAX_SFILES];
Bool VG_(clo_profile) = False;
@@ -558,6 +560,7 @@
" -q --quiet run silently; only print error msgs\n"
" -v --verbose be more verbose, incl counts of errors\n"
" --gdb-attach=no|yes start GDB when errors detected? [no]\n"
+" --gdb-command=<command> command to run as gdb [gdb]\n"
" --demangle=no|yes automatically demangle C++ names? [yes]\n"
" --num-callers=<number> show <num> callers in stack traces [4]\n"
" --error-limit=no|yes stop showing new errors if too many? [yes]\n"
@@ -567,6 +570,7 @@
" --run-libc-freeres=no|yes Free up glibc memory at exit? [yes]\n"
" --logfile-fd=<number> file descriptor for messages [2=stderr]\n"
" --logfile=<file> log messages to <file>.pid<pid>\n"
+" --input-fd=<number> file descriptor for input [0=stdin]\n"
" --logsocket=ipaddr:port log messages to socket ipaddr:port\n"
" --suppressions=<filename> suppress errors described in\n"
" suppressions file <filename>\n"
@@ -859,6 +863,9 @@
else if (STREQ(argv[i], "--gdb-attach=no"))
VG_(clo_GDB_attach) = False;
+ else if (STREQN(14,argv[i], "--gdb-command="))
+ VG_(clo_GDB_command) = &argv[i][14];
+
else if (STREQ(argv[i], "--demangle=yes"))
VG_(clo_demangle) = True;
else if (STREQ(argv[i], "--demangle=no"))
@@ -896,6 +903,9 @@
VG_(clo_logfile_name) = &argv[i][10];
}
+ else if (STREQN(11, argv[i], "--input-fd="))
+ VG_(clo_input_fd) = (Int)VG_(atoll)(&argv[i][11]);
+
else if (STREQN(12, argv[i], "--logsocket=")) {
VG_(clo_log_to) = VgLogTo_Socket;
VG_(clo_logfile_name) = &argv[i][12];
@@ -1673,7 +1683,8 @@
Int res;
UChar buf[100];
VG_(sprintf)(buf,
- "/usr/bin/gdb -nw /proc/%d/exe %d",
+ "%s -nw /proc/%d/exe %d",
+ VG_(clo_GDB_command),
VG_(getpid)(), VG_(getpid)());
VG_(message)(Vg_UserMsg, "starting GDB with cmd: %s", buf);
res = VG_(system)(buf);
|
|
From: Dan K. <da...@ke...> - 2003-05-13 04:28:39
|
Julian Seward wrote: > Attached is a patch which allows you to change stdin to whatever > you like, if you thing V is closing it. I tried the new --gdb-command= option, setting it to a shell script containing DISPLAY=x.y.z.w:0.0 xterm -e gdb "$@" and it worked nicely. I'll try the other option next. I've already posted an interesting stack dump to de...@op... using this. +1 for getting this into the upcoming release of valgrind! Thanks, Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X