Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 327507

Summary:

MemoryProxy not properly processing non-zero offsets in range containing multiple entries

Product:

[Tools] TCF

Reporter:

Kirk Beitz <kirk.beitz>

Component:

Core

Assignee:

Project Inbox <dsdp.tm.tcf-inbox>

Status:

RESOLVED FIXED

QA Contact:

Martin Oberhuber <mober.at+eclipse>

Severity:

critical

Priority:

CC:

cdtdoug, eugene

Version:

unspecified

Target Milestone:

0.4.0

Hardware:

All

OS:

All

Whiteboard:

Attachments:

Description	Flags
bugfix to subtract original address from error address to get offset (includes changes found in patch in Bug 326270)	eugene: iplog+

Description Kirk Beitz

2010-10-12 02:27:11 EDT

Created attachment 180635 [details]
bugfix to subtract original address from error address to get offset (includes changes found in patch in Bug 326270)

org.eclipse.tm.internal.tcf.services.remote.MemoryProxy.MemoryErrorReport.MemoryErrorReport() appears to contain a bug w.r.t. the processing of addresses that are offset from the originally requested address passed as a parameter to org.eclipse.tm.internal.tcf.services.remote.MemoryProxy.MemContext.get() .

this snippet of code (also seen in the attached patch) appears to be incorrect:

                BigInteger addr_bi = addr instanceof BigInteger ?
                        (BigInteger)addr : new BigInteger(addr.toString());
                for (Map<String,Object> m : c) {
                    Range r = new Range();
                    Number x = (Number)m.get(RANGE_KEY_ADDR);
                    BigInteger y = x instanceof BigInteger ?
                            (BigInteger)x : new BigInteger(x.toString());
this call =======>  r.offs = y.subtract(addr_bi).intValue();
                    r.size = ((Number)m.get(RANGE_KEY_SIZE)).intValue();
                    r.stat = ((Number)m.get(RANGE_KEY_STAT)).intValue();
                    r.msg = Command.toErrorString(m.get(RANGE_KEY_MSG));
causes this =====>  assert r.offs >= 0;
to fire the         assert r.size >= 0;
second time         this.ranges[n++] = r;
thru the loop   }

it would seem to be more appropriate to have it be

better ==========>  r.offs = addr_bi.subtract(y).intValue();

making this a critical due to it blocking the ability to implement an agent mechanism to send back address blocks in a single TCF message that are at appropriate offests.

Comment 1 Kirk Beitz

2010-10-12 02:31:00 EDT

arrgh … why can't you edit own mistakes in bugzilla?!?

the bad snippet and the better substitution in the description are inverted!!!


try the following instead:

this snippet of code (also seen in the attached patch) appears to be incorrect:

                BigInteger addr_bi = addr instanceof BigInteger ?
                        (BigInteger)addr : new BigInteger(addr.toString());
                for (Map<String,Object> m : c) {
                    Range r = new Range();
                    Number x = (Number)m.get(RANGE_KEY_ADDR);
                    BigInteger y = x instanceof BigInteger ?
                            (BigInteger)x : new BigInteger(x.toString());
this call =======>  r.offs = addr_bi.subtract(y).intValue();
                    r.size = ((Number)m.get(RANGE_KEY_SIZE)).intValue();
                    r.stat = ((Number)m.get(RANGE_KEY_STAT)).intValue();
                    r.msg = Command.toErrorString(m.get(RANGE_KEY_MSG));
causes this =====>  assert r.offs >= 0;
to fire the         assert r.size >= 0;
second time         this.ranges[n++] = r;
thru the loop   }


it would seem to be more appropriate to have it be

better ==========>  r.offs = y.subtract(addr_bi).intValue();

Comment 2 Eugene Tarassov

2010-10-12 19:37:54 EDT

subtract() method has a mystical power to get its arguments inverted :-)
Yes, it a bug. I have committed the patch.
Thanks!

Comment 3 Doug Schaefer

2011-05-17 10:49:47 EDT

Moving bugs to new home for IP log.

Comment 4 Martin Oberhuber

2013-06-05 06:27:17 EDT

Bulk change: Marking all bugs from the TM era (until June 2011) target 0.3