|
From: Nicholas N. <nj...@ca...> - 2004-04-08 14:26:09
|
On Thu, 8 Apr 2004, G B wrote: > > That output looks like the relevant part of the program has been > > stripped of both debug info and symbol tables. But if you are > > compiling with -g, that shouldn't be the case. Are you compiling with > > -fomit-frame-pointer? That could be a problem. > > I'm compiling like this: > > CC=g++ > LFLAGS=-L/usr/X11R6/lib -lGL -lGLU -lglut -lm -lXi > -lXmu `/usr/bin/sdl-config --libs` -lSDL_image > CFLAGS=-Wall -Wno-parentheses -fstack-check > `/usr/bin/sdl-config --cflags` > > $(CC) -g -o main $(OBJS) $(LFLAGS) $(CFLAGS) Hmm, maybe -fstack-check is confusing Valgrind? N |
|
From: Nicholas N. <nj...@ca...> - 2004-04-08 16:24:54
|
On Thu, 8 Apr 2004, G B wrote: > > > CC=g++ > > > LFLAGS=-L/usr/X11R6/lib -lGL -lGLU -lglut -lm -lXi > > > -lXmu `/usr/bin/sdl-config --libs` -lSDL_image > > > CFLAGS=-Wall -Wno-parentheses -fstack-check > > > `/usr/bin/sdl-config --cflags` > > > > > > $(CC) -g -o main $(OBJS) $(LFLAGS) $(CFLAGS) > > > > Hmm, maybe -fstack-check is confusing Valgrind? > > Yes it was. Hmm. > > Well, the only error I get from my program when I run > it now is this: > > ==3017== Invalid free() / delete / delete[] > ==3017== at 0x7501CDEC: free (in > /usr/lib/valgrind/vgpreload_addrcheck.so) > ==3017== by 0x7540B9B3: (within /lib/libc-2.3.3.so) > ==3017== by 0x7540B6F9: __libc_freeres (in > /lib/libc-2.3.3.so) > ==3017== by 0x75018BBE: (within > /usr/lib/valgrind/vg_inject.so) > ==3017== Address 0x759D0818 is not stack'd, malloc'd > or free'd > > Is this valgrind finding a bug in > a) itself? > b) libc? > c) my program? Maybe b, maybe c. A longer stack trace (eg. --num-callers=20) will hopefully make it clearer. N |
|
From: <gil...@ya...> - 2004-04-09 16:01:52
|
--- Nicholas Nethercote <nj...@ca...> wrote: > > Is this valgrind finding a bug in > > a) itself? > > b) libc? > > c) my program? > > Maybe b, maybe c. A longer stack trace (eg. > --num-callers=20) will > hopefully make it clearer. ==2872== Invalid free() / delete / delete[] ==2872== at 0x7501CDEC: free (in /usr/lib/valgrind/vgpreload_addrcheck.so) ==2872== by 0x7540B9B3: (within /lib/libc-2.3.3.so) ==2872== by 0x7540B6F9: __libc_freeres (in /lib/libc-2.3.3.so) ==2872== by 0x75018BBE: (within /usr/lib/valgrind/vg_inject.so) ==2872== by 0x7533104A: exit (in /lib/libc-2.3.3.so) ==2872== by 0x75106C19: processEventsAndTimeouts (in /usr/lib/libglut.so.3.7.1) ==2872== by 0x8F: ??? ==2872== Address 0x759D0818 is not stack'd, malloc'd or free'd The above was obtained with --num-callers=20. Any ideas what could be lurking at 0x8F? ____________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html |
|
From: Nicholas N. <nj...@ca...> - 2004-04-09 22:39:30
|
On Fri, 9 Apr 2004, G B wrote: > --- Nicholas Nethercote <nj...@ca...> wrote: > > > Is this valgrind finding a bug in > > > a) itself? > > > b) libc? > > > c) my program? > > > > Maybe b, maybe c. A longer stack trace (eg. > > --num-callers=20) will > > hopefully make it clearer. > > ==2872== Invalid free() / delete / delete[] > ==2872== at 0x7501CDEC: free (in > /usr/lib/valgrind/vgpreload_addrcheck.so) > ==2872== by 0x7540B9B3: (within /lib/libc-2.3.3.so) > ==2872== by 0x7540B6F9: __libc_freeres (in > /lib/libc-2.3.3.so) > ==2872== by 0x75018BBE: (within > /usr/lib/valgrind/vg_inject.so) > ==2872== by 0x7533104A: exit (in > /lib/libc-2.3.3.so) > ==2872== by 0x75106C19: processEventsAndTimeouts > (in /usr/lib/libglut.so.3.7.1) > ==2872== by 0x8F: ??? > ==2872== Address 0x759D0818 is not stack'd, malloc'd > or free'd > > The above was obtained with --num-callers=20. Any > ideas what could be lurking at 0x8F? Stack-walking is not always reliable, I think Valgrind's getting confused here, and wouldn't pay too much attention to the 0x8f. Try with --run-libc-freeres=no. If you don't get an error, then I think it shows that the problem is with glibc -- libc-freeres is a glibc routine that frees up all glibc's memory. N |
|
From: <gil...@ya...> - 2004-04-10 18:30:07
|
> > The above was obtained with --num-callers=20. Any > > ideas what could be lurking at 0x8F? > > Stack-walking is not always reliable, I think > Valgrind's getting confused > here, and wouldn't pay too much attention to the > 0x8f. Try with > --run-libc-freeres=no. If you don't get an error, > then I think it shows > that the problem is with glibc -- libc-freeres is a > glibc routine that > frees up all glibc's memory. There is no error with --run-libc-freeres=no. I guess that solves that one then. That said, why does glibc have this problem? ____________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html |
|
From: Nicholas N. <nj...@ca...> - 2004-04-10 18:50:31
|
On Sat, 10 Apr 2004, G B wrote: > There is no error with --run-libc-freeres=no. I guess > that solves that one then. Yes, sounds like a glibc bug. > That said, why does glibc have this problem? glibc has bugs, just like any other program :) N |
|
From: Henrik N. <hn...@ma...> - 2004-04-11 00:00:41
|
On Sat, 10 Apr 2004, G B wrote: > There is no error with --run-libc-freeres=no. I guess > that solves that one then. That said, why does glibc > have this problem? Probably because very few developers uses the freeres function in glibc as it is only relevant for leak checkers, so bugs is very likely to appear in this part of glibc. Regards Henrik |
|
From: tmoog <tm...@sa...> - 2004-04-08 16:34:22
|
I have noticed that when a .so is loaded via dlopen and it is unloaded via dlclose before exit then valgrind doesn't know how to resolve the symbols for that .so. Nicholas Nethercote wrote: > On Thu, 8 Apr 2004, G B wrote: > > > > > CC=g++ > > > > LFLAGS=-L/usr/X11R6/lib -lGL -lGLU -lglut -lm -lXi > > > > -lXmu `/usr/bin/sdl-config --libs` -lSDL_image > > > > CFLAGS=-Wall -Wno-parentheses -fstack-check > > > > `/usr/bin/sdl-config --cflags` > > > > > > > > $(CC) -g -o main $(OBJS) $(LFLAGS) $(CFLAGS) > > > > > > Hmm, maybe -fstack-check is confusing Valgrind? > > > > Yes it was. Hmm. > > > > Well, the only error I get from my program when I run > > it now is this: > > > > ==3017== Invalid free() / delete / delete[] > > ==3017== at 0x7501CDEC: free (in > > /usr/lib/valgrind/vgpreload_addrcheck.so) > > ==3017== by 0x7540B9B3: (within /lib/libc-2.3.3.so) > > ==3017== by 0x7540B6F9: __libc_freeres (in > > /lib/libc-2.3.3.so) > > ==3017== by 0x75018BBE: (within > > /usr/lib/valgrind/vg_inject.so) > > ==3017== Address 0x759D0818 is not stack'd, malloc'd > > or free'd > > > > Is this valgrind finding a bug in > > a) itself? > > b) libc? > > c) my program? > > Maybe b, maybe c. A longer stack trace (eg. --num-callers=20) will > hopefully make it clearer. > > N > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Nicholas N. <nj...@ca...> - 2004-04-10 01:10:22
|
On Thu, 8 Apr 2004, tmoog wrote: > I have noticed that when a .so is loaded via dlopen and it is > unloaded via dlclose before exit then valgrind doesn't know > how to resolve the symbols for that .so. Yes. I just committed a PR for that (http://bugs.kde.org/show_bug.cgi?id=79362) if you are interested. Not that this implies anything will be done immediately; this has been a problem since Valgrind was born. N |