|
From: Yuri <yu...@ra...> - 2006-01-31 00:24:02
|
I tried to catch the prob lem in the simple testcase and VG says it's no problem.
Why wouldn't it find such simple issue?
I use valgrind-3.0.1 on amd64 platform.
Thanx,
Yuri
---- testcase -----
main() {
int *pi = new int;
pi[-100] = 1;
delete pi;
}
|
|
From: Julian S. <js...@ac...> - 2006-01-31 00:36:32
|
On Tuesday 31 January 2006 00:23, Yuri wrote:
> I tried to catch the prob lem in the simple testcase and VG says it's no
> problem.
>
> Why wouldn't it find such simple issue?
>
> I use valgrind-3.0.1 on amd64 platform.
>
> Thanx,
> Yuri
>
>
> ---- testcase -----
> main() {
> int *pi = new int;
> pi[-100] = 1;
> delete pi;
> }
It can only catch probably pi[-1] .. pi[-4] and
pi[100] .. pi[103], since the block red-zones are 16-bytes long.
At least if I remember right they are.
J
|
|
From: Yuri <yu...@ra...> - 2006-01-31 00:42:33
|
I have the issue that my program seems to corrupt memory allocation internal
structures.
Thery might be outside the red zones but still.
Seems like valgrind should be finding such things but it doesn't.
Any way I can make VG to give errors on all writes outside of allocated
by mallocs arear?
Yuri
Quoting Julian Seward <js...@ac...>:
> On Tuesday 31 January 2006 00:23, Yuri wrote:
> > I tried to catch the prob lem in the simple testcase and VG says it's no
> > problem.
> >
> > Why wouldn't it find such simple issue?
> >
> > I use valgrind-3.0.1 on amd64 platform.
> >
> > Thanx,
> > Yuri
> >
> >
> > ---- testcase -----
> > main() {
> > int *pi = new int;
> > pi[-100] = 1;
> > delete pi;
> > }
>
> It can only catch probably pi[-1] .. pi[-4] and
> pi[100] .. pi[103], since the block red-zones are 16-bytes long.
> At least if I remember right they are.
>
> J
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
--
|
|
From: Nicholas N. <nj...@cs...> - 2006-01-31 11:06:56
|
On Mon, 30 Jan 2006, Yuri wrote: > Seems like valgrind should be finding such things but it doesn't. Life is tough sometimes, yes? > Any way I can make VG to give errors on all writes outside of allocated > by mallocs arear? No. Nick |
|
From: Jorrit T. <jor...@gm...> - 2006-01-31 11:16:40
|
On 1/31/06, Nicholas Nethercote <nj...@cs...> wrote: > On Mon, 30 Jan 2006, Yuri wrote: > > > Seems like valgrind should be finding such things but it doesn't. > > Life is tough sometimes, yes? > > > Any way I can make VG to give errors on all writes outside of allocated > > by mallocs arear? > > No. > Perhaps it would be nice to have an option to increase the block red zones or something. Not sure if that is possible or easy to do. Greetings, -- Project Manager of Crystal Space (http://www.crystalspace3d.org) and CEL (http://cel.crystalspace3d.org) Support Crystal Space. Donate at https://sourceforge.net/donate/index.php?group_id=3D649 |
|
From: Paul P. <ppl...@gm...> - 2006-01-31 05:41:58
|
On 1/30/06, Yuri <yu...@ra...> wrote:
> I tried to catch the prob lem in the simple testcase and VG says it's no =
problem.
> Why wouldn't it find such simple issue?
Most likely because 'pi[-100]' falls into .data section for the
executable, and it is perfectly legal to write there.
> main() {
> int *pi =3D new int;
> pi[-100] =3D 1;
> delete pi;
> }
FWIW, here is what Insure++ from www.parasoft.com reports:
[test.c:3] **WRITE_BAD_INDEX**
>> pi[-100] =3D 1;
Writing array out of range: pi[-100]
Index used : -100
In block : 0x0000000000503060 thru 0x0000000000503063 (4 bytes)
pi, allocated at test.c, 2
malloc() (interface)
operator new()
main() test.c, 2
Stack trace where the error occurred:
main() test.c, 3
**Memory corrupted. Program may crash!!**
Cheers,
|
|
From: Dirk M. <dm...@gm...> - 2006-01-31 12:04:05
|
On Tuesday 31 January 2006 12:06, Nicholas Nethercote wrote: > > Any way I can make VG to give errors on all writes outside of allocated > > by mallocs arear? > No. Why not? the problem here is that it happens to hit a memory page that is mapped as writeable (global offset table?). One possible workaround for this would be to add big red zones around the heap area (32 MB or something like that) and then we'd be able to catch writes there. Doesn't sound too complicated, does it? Dirk |
|
From: Nicholas N. <nj...@cs...> - 2006-01-31 20:46:31
|
On Tue, 31 Jan 2006, Dirk Mueller wrote: >>> Any way I can make VG to give errors on all writes outside of allocated >>> by mallocs arear? >> No. > > Why not? the problem here is that it happens to hit a memory page that is > mapped as writeable (global offset table?). One possible workaround for this > would be to add big red zones around the heap area (32 MB or something like > that) and then we'd be able to catch writes there. Doesn't sound too > complicated, does it? It'll catch a small number, but it won't solve the general case. You needs bounds-checking for that. Or using DieHard's approach (http://www.cs.umass.edu/~emery/diehard/) will get you partway there, but I don't think that approach is a good one to use in Valgrind. Nick |
|
From: Dirk M. <dm...@gm...> - 2006-02-01 13:59:06
|
On Tuesday 31 January 2006 21:46, Nicholas Nethercote wrote: > It'll catch a small number, but it won't solve the general case. Sure it doesn't solve 100%, but if it makes it work a bit more for some cases where valgrind fails (and its not something that I think would be more work than a couple of lines of code in the right place), then I don't see anything wrong with it. I'm not sure if you ever experienced such bugs where neither valgrind nor efence help in a code base that is 100k LOC and the only way to find the memory corruption is by selectively disabling code until you narrowed it down to a small chunk that you can instrument with printf's. This is an insanely painful experience and if valgrind can do a little bit (even with a --enable-weird-hacks-for-dirk switch), then that would have saved me hours of painful and very boring work. Dirk |
|
From: Julian S. <js...@ac...> - 2006-02-01 14:57:52
|
On Wednesday 01 February 2006 13:58, Dirk Mueller wrote: > On Tuesday 31 January 2006 21:46, Nicholas Nethercote wrote: > > It'll catch a small number, but it won't solve the general case. > > Sure it doesn't solve 100%, but if it makes it work a bit more for some > cases where valgrind fails (and its not something that I think would be > more work than a couple of lines of code in the right place), then I don't > see anything wrong with it. > > I'm not sure if you ever experienced such bugs where neither valgrind nor > efence help in a code base that is 100k LOC and the only way to find the > memory corruption is by selectively disabling code until you narrowed it > down to a small chunk that you can instrument with printf's. It's a fair point. We could surely implement it without too much difficulty by some hacking in m_mallocfree.c, in which we put a giant redzone (eg, 128k) at the start and end of each struct _Superblock which belongs to VG_AR_CLIENT. It would require some attention to detail. Also would require a way in which we can tell memcheck that the redzone is no-access. > This is an > insanely painful experience and if valgrind can do a little bit (even with > a --enable-weird-hacks-for-dirk switch), then that would have saved me > hours of painful and very boring work. For this particular case, can you tell us a bit more about it? Perhaps there are other possible hacks that would have helped you, eg, large redzones on individual allocations. J |
|
From: Dirk M. <dm...@gm...> - 2006-02-01 15:11:36
|
On Wednesday 01 February 2006 15:57, Julian Seward wrote: > For this particular case, can you tell us a bit more about it? its the latest xpdf exploit, see https://bugzilla.novell.com/show_bug.cgi?id=141242, or run xpdf/kpdf against page 12 of http://www.marantz.com/pdfs/g_sr7500_man.pdf). It did a write afaik 36 bytes in front of the allocated bitmap buffer, which valgrind was unable to catch. > Perhaps there are other possible hacks that would have helped you, > eg, large redzones on individual allocations. larger redzones could have helped I guess. I also tried stuff like --alignment=8192 but it didn't trigger helpful output. Only commenting out in this highly recursive pdf parser helped narrowing down until the error cause was obvious. Dirk |
|
From: Paul P. <ppl...@gm...> - 2006-02-10 23:52:26
|
On 2/1/06, Dirk Mueller <dm...@gm...> wrote: > > https://bugzilla.novell.com/show_bug.cgi?id=3D141242, or run xpdf/kpdf ag= ainst > page 12 of http://www.marantz.com/pdfs/g_sr7500_man.pdf). It did a write > afaik 36 bytes in front of the allocated bitmap buffer, which valgrind wa= s > unable to catch. Just for the record: - It took me 10 minutes to find the bug with Insure++ (www.parasoft.com), report below - The bug is an underflow of malloc area by 1 byte -- VG should have no trouble finding this bug (but VG 3.1.0 doesn't). - Unlike in the case that started this thread, the corrupted area is smack in the middle of heap (there have been thousands of malloc()s performed before that point), so I don't think guard pages around "whole heap" would have helped. - I also tested xpdf-3.01pl2, which came "clean", except for the new read-uninit issue, report below. Cheers, =3D=3D=3D xpdf-3.00 =3D=3D=3D [Splash.cc:817] **WRITE_OVERFLOW** >> *mono8 =3D color.mono8; Writing overflows memory: mono8 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb | 1 | 25 | wwwww Writing (w) : 0x088fd74f thru 0x088fd74f (1 byte) To block (b) : 0x088fd750 thru 0x088fd768 (25 bytes) block allocated at gmem.c, 89 malloc() pc: 0x00cf72fe (interface) gmalloc() pc: 0x08457085 gmem.c, 89 SplashBitmap::SplashBitmap() pc: 0x084787cf SplashBitmap.cc, 34 SplashOutputDev::type3D1() pc: 0x083127b8 SplashOutputDev.cc, 108= 6 Gfx::opSetCacheDevice() pc: 0x080f88f8 Gfx.cc, 3008 Gfx::execOp() pc: 0x080e49fa Gfx.cc, 660 Gfx::go() pc: 0x08104818 Gfx.cc, 551 Gfx::display() pc: 0x08105fcb Gfx.cc, 523 Gfx::doShowText() pc: 0x08119699 Gfx.cc, 2382 Gfx::opShowText() pc: 0x0811dd32 Gfx.cc, 2238 Gfx::execOp() pc: 0x080e49fa Gfx.cc, 660 Gfx::go() pc: 0x08104818 Gfx.cc, 551 Gfx::display() pc: 0x08105fcb Gfx.cc, 523 Page::displaySlice() pc: 0x082a4390 Page.cc, 319 Page::display() pc: 0x082a52f5 Page.cc, 226 PDFDoc::displayPage() pc: 0x082b526b PDFDoc.cc, 218 XPDFCore::displayPage() pc: 0x083c696a XPDFCore.cc, 513 XPDFViewer::displayPage() pc: 0x083e1a8b XPDFViewer.cc, 272 XPDFViewer::pageNumCbk() pc: 0x083fb84b XPDFViewer.cc, 1516 XtCallCallbackList() pc: 0x00d8f91c _XmTextFieldSetDestination() pc: 0x00664703 _XtMatchAtom() pc: 0x00dc1caa _XtMatchAtom() pc: 0x00dc227a _XtTranslateEvent() pc: 0x00dc27fc XtDispatchEventToWidget() pc: 0x00d9d2d0 _XtOnGrabList() pc: 0x00d9db9c XtDispatchEvent() pc: 0x00d9dd6a XtAppMainLoop() pc: 0x00d9e186 XPDFApp::run() pc: 0x083b56d9 XPDFApp.cc, 290 main() pc: 0x0844190f xpdf.cc, 288 Stack trace where the error occurred: Splash::drawSpan() pc: 0x08460049 Splash.cc, 817 Splash::fillWithPattern() pc: 0x0846110f Splash.cc, 649 Splash::fill() pc: 0x084769ad Splash.cc, 621 SplashOutputDev::fill() pc: 0x0830f92d SplashOutputDev.cc, 735 Gfx::opFill() pc: 0x08116de4 Gfx.cc, 1140 Gfx::execOp() pc: 0x080e49fa Gfx.cc, 660 Gfx::go() pc: 0x08104818 Gfx.cc, 551 Gfx::display() pc: 0x08105fcb Gfx.cc, 523 Gfx::doShowText() pc: 0x08119699 Gfx.cc, 2382 Gfx::opShowText() pc: 0x0811dd32 Gfx.cc, 2238 Gfx::execOp() pc: 0x080e49fa Gfx.cc, 660 Gfx::go() pc: 0x08104818 Gfx.cc, 551 Gfx::display() pc: 0x08105fcb Gfx.cc, 523 Page::displaySlice() pc: 0x082a4390 Page.cc, 319 Page::display() pc: 0x082a52f5 Page.cc, 226 PDFDoc::displayPage() pc: 0x082b526b PDFDoc.cc, 218 XPDFCore::displayPage() pc: 0x083c696a XPDFCore.cc, 513 XPDFViewer::displayPage() pc: 0x083e1a8b XPDFViewer.cc, 272 XPDFViewer::pageNumCbk() pc: 0x083fb84b XPDFViewer.cc, 1516 XtCallCallbackList() pc: 0x00d8f91c _XmTextFieldSetDestination() pc: 0x00664703 _XtMatchAtom() pc: 0x00dc1caa _XtMatchAtom() pc: 0x00dc227a _XtTranslateEvent() pc: 0x00dc27fc XtDispatchEventToWidget() pc: 0x00d9d2d0 _XtOnGrabList() pc: 0x00d9db9c XtDispatchEvent() pc: 0x00d9dd6a XtAppMainLoop() pc: 0x00d9e186 XPDFApp::run() pc: 0x083b56d9 XPDFApp.cc, 290 main() pc: 0x0844190f xpdf.cc, 288 =3D=3D=3D xpdf-3.00 =3D=3D=3D =3D=3D=3D xpdf-3.01pl2 =3D=3D=3D [Splash.cc:515] **READ_UNINIT_MEM(read)** >> if (nClipRes[splashClipPartial] || Reading uninitialized memory: nClipRes[splashClipPartial] Stack trace where the error occurred: Splash::strokeNarrow() Splash.cc, 515 Splash::stroke() Splash.cc, 413 SplashOutputDev::stroke() SplashOutputDev.cc, 1259 Gfx::opStroke() Gfx.cc, 1168 Gfx::execOp() Gfx.cc, 675 Gfx::go() Gfx.cc, 566 Gfx::display() Gfx.cc, 538 Page::displaySlice() Page.cc, 317 PDFDoc::displayPageSlice() PDFDoc.cc, 361 PDFCore::needTile() PDFCore.cc, 790 PDFCore::update() PDFCore.cc, 615 XPDFCore::update() XPDFCore.cc, 305 PDFCore::displayPage() PDFCore.cc, 257 XPDFViewer::displayPage() XPDFViewer.cc, 263 XPDFViewer::XPDFViewer() XPDFViewer.cc, 170 XPDFApp::open() XPDFApp.cc, 224 main() xpdf.cc, 294 =3D=3D=3D xpdf-3.01pl2 =3D=3D=3D |
|
From: Dirk M. <dm...@gm...> - 2006-02-14 11:52:36
|
On Saturday, 11. February 2006 00:52, Paul Pluzhnikov wrote: > - It took me 10 minutes to find the bug with Insure++ > (www.parasoft.com), report below Did you use the Chaperon tool or did you recompile with purify? > - The bug is an underflow of malloc area by 1 byte -- VG > should have no trouble finding this bug (but VG 3.1.0 doesn't). I'm aware. The question is how to deduce a testcase from it... to see why valgrind fails. This is the hard part. Dirk |
|
From: Julian S. <js...@ac...> - 2006-02-14 12:36:44
|
On Tuesday 14 February 2006 11:54, Dirk Mueller wrote: > > - The bug is an underflow of malloc area by 1 byte -- VG > > should have no trouble finding this bug (but VG 3.1.0 doesn't). > > I'm aware. The question is how to deduce a testcase from it... to see why > valgrind fails. This is the hard part. If you can come up with a test case - even a large one - I'll be happy to chase it from there. J |
|
From: Paul P. <ppl...@gm...> - 2006-02-14 14:29:12
|
On 2/14/06, Dirk Mueller <dm...@gm...> wrote: > On Saturday, 11. February 2006 00:52, Paul Pluzhnikov wrote: > > > - It took me 10 minutes to find the bug with Insure++ > > (www.parasoft.com), report below > > Did you use the Chaperon tool or did you recompile with purify? Both Chaperon and Insure instrumentation (which is different from Purify) do find the bug. > > - The bug is an underflow of malloc area by 1 byte -- VG > > should have no trouble finding this bug (but VG 3.1.0 doesn't). > > I'm aware. That's not how you described the bug originally: DM> It did a write DM> afaik 36 bytes in front of the allocated bitmap buffer, which valgrind= was DM> unable to catch. On 2/14/06, Julian Seward <js...@ac...> wrote: > If you can come up with a test case - even a large one - I'll be > happy to chase it from there. The test case was described in Dirk's message from Feb 1, 2006: build xpdf-3.00 and run it against page 12 of=20 http://www.marantz.com/pdfs/g_sr7500_man.pdf: xpdf-3.00/xpdf/xpdf g_sr7500_man.pdf 12 VG3.1.0 remains silent (on RH-9 and FC4), but without VG the program crashe= s. Cheers, |
|
From: Dirk M. <dm...@gm...> - 2006-02-14 14:42:46
|
On Tuesday, 14. February 2006 15:29, Paul Pluzhnikov wrote: > > Did you use the Chaperon tool or did you recompile with purify? > Both Chaperon and Insure instrumentation (which is different from > Purify) do find the bug. Sorry, mixed up the product name :) Ok, if Chaperon catches it then there is something seriously wrong for the valgrind case. > > > - The bug is an underflow of malloc area by 1 byte -- VG > > > should have no trouble finding this bug (but VG 3.1.0 doesn't). > > I'm aware. > That's not how you described the bug originally: I'm aware that VG 3.1.0 does not catch the underflow. I stopped at some place finding out which particular write corrupted the memory, because it was obvious that the coordinates were off the buffer boundaries. Dirk |
|
From: Julian S. <js...@ac...> - 2006-02-14 15:06:58
|
So I'm confused. Dirk: did you see Valgrind missing an underflow of a malloc area by 1 byte? Or was it 36 bytes? J On Tuesday 14 February 2006 14:44, Dirk Mueller wrote: > On Tuesday, 14. February 2006 15:29, Paul Pluzhnikov wrote: > > > Did you use the Chaperon tool or did you recompile with purify? > > > > Both Chaperon and Insure instrumentation (which is different from > > Purify) do find the bug. > > Sorry, mixed up the product name :) Ok, if Chaperon catches it then there > is something seriously wrong for the valgrind case. > > > > > - The bug is an underflow of malloc area by 1 byte -- VG > > > > should have no trouble finding this bug (but VG 3.1.0 doesn't). > > > > > > I'm aware. > > > > That's not how you described the bug originally: > > I'm aware that VG 3.1.0 does not catch the underflow. I stopped at some > place finding out which particular write corrupted the memory, because it > was obvious that the coordinates were off the buffer boundaries. > > > Dirk > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Dirk M. <dm...@gm...> - 2006-02-14 15:18:59
|
On Tuesday, 14. February 2006 16:06, Julian Seward wrote: > So I'm confused. Dirk: did you see Valgrind missing an underflow of > a malloc area by 1 byte? Or was it 36 bytes? It IIRC writes several times outside the range of the bitmap buffer. The first write is most likely the mentioned 1 byte underflow, the next one is 1 byte + width_of_image, the next one is 1 byte + 2*width_of_image and so on. Insure apparently managed to capture the first write successfully. I didn't, because I couldn't find a tool that does so, and I only found the offending wrong coordinate which later then caused the out of bounds write. I didn't actually tracked down which particular write was the first one corrupting memory. I just found one of the offenders and that was enough :) Dirk |
|
From: Paul P. <ppl...@gm...> - 2006-02-14 17:05:54
|
On 2/14/06, Dirk Mueller <dm...@gm...> wrote: > It IIRC writes several times outside the range of the bitmap buffer. The = first > write is most likely the mentioned 1 byte underflow, the next one is 1 by= te + > width_of_image, the next one is 1 byte + 2*width_of_image and so on. That's not what Insure/Chaperon "sees". They only see the one underflow by one byte I sent on Feb 10 (when invoked with "Chaperon xpdf/xpdf g_sr7500_man.pdf 12"). Cheers, |