StackOverflowError from FileRecord.readData when attribute list points to parent record

Project:JNode FS
Component:Code
Category:bug report
Priority:normal
Assigned:Daniel Noll
Status:closed
Description

We have found 4 disks where the attribute list points back into the current record for some attribute entries.

I'm working on a fix but as usual Sad can't provide any sample data for unit testing.

It should also fix something else I noticed, which is that if there are multiple attribute lists stored outside the record and an error occurs on the first one, the rest won't be looked at. Well, this one is minor in comparison.

#1

Submitted by Daniel Noll on Tue, 12/02/2008 - 02:02.

Attached patch fixes this problem and the subsequent problem I discovered in the same area after fixing it (although it seems this one was caused by a disk which some other software also found to be bad, it _did_ cause an infinite loop in this case so it was worth fixing anyway.)

Hopefully this patch is okay... admittedly I generated it from our vendor branch instead of the clean trunk, so let me know if there is an issue and I'll update trunk and re-merge. But I figure there hasn't been much action on this fs driver lately so it will probably be okay. Smiling

AttachmentSize
attribute-list-points-to-self.patch3.39 KB

#2

Submitted by Daniel Noll on Tue, 12/02/2008 - 02:08.
Status:active» patch (code needs review)

#3

Submitted by lsantha on Tue, 12/02/2008 - 09:33.

I've tried to apply the patch but it was rejected.
One reason might be that the code was reformatted in the meantime.
It would be best if you updated your custom sources too and resubmitted a valid patch.
Thank you.

#4

Submitted by Peter on Thu, 03/26/2009 - 15:00.

Hey Daniel, I tried to apply your patch with "ignore-whitespaces" but trunk changed already too much. It might be even possible that parts of it already are in trunk.
Could you check and resubmit your patch?

#5

Submitted by Daniel Noll on Thu, 03/26/2009 - 22:02.
Status:patch (code needs review)» closed

Looks like it's no longer needed. This chunk of code in trunk is the equivalent:

    // If it's resident (i.e. in the current file record) then we don't need to
    // look it up, and doing so would risk infinite recursion.
    FileRecord holdingRecord;
    if (entry.getFileReferenceNumber() == referenceNumber) {
        holdingRecord = FileRecord.this;
    } else {
        holdingRecord = getVolume().getMFT().getRecord(entry.getFileReferenceNumber());
    }